文章目录
前言
本文主要是为了记录我自己在编写GoDance集群模块时遇到的一些问题和当时的思考以及解决方案
正文
分布式一致如何去做？
当时有两种方式实现共识算法，一种是ES的默认发现模块（采用Gossip算法），一种采用强一致性的craft算法。
写设计方案的时候一开始是参照ES的来做的，但是发现了一些问题，网上也说明了一些问题，最后决定改用已经证明过正确性的Raft算法来实现分布式一致。
超时RPC如何去做？
利用管道和定时器，但是有gorutine泄露的问题，这让我想到能不能主动关闭gorutine，查询了资料后得到的答案是不能，这确实是合乎常理的
在 Go issues 中也有人提过类似问题，Dave Cheney 给出了一些思考：
- 如果一个 goroutine 被强行停止了，它所拥有的资源会发生什么？堆栈被解开了吗？defer 是否被执行？
- 如果执行 defer，该 goroutine 可能可以继续无限期地生存下去。
- 如果不执行 defer，该 goroutine 原本的应用程序系统设计逻辑将会被破坏，这肯定不合理。
- 如果允许强制停止 goroutine，是要释放所有东西，还是直接把它从调度器中踢出去，你想通过此解决什么问题？
所以gorutine只能主动去退出
停止 Goroutine 有几种方法？ - 侃豺小哥 - 博客园 (cnblogs.com)
否定了这种方案后，我在网上又找到了其他思路，RPC通信基于底层网络通信，可以通过设置connection的读写超时时间，达到RPC读写超时的目的
翻了半天资料发现16年有一条冻结该包的issue
最后在他的标准库官方文档中发现，该包冻结不接受新功能，完美踩坑，我谢谢你！
最终使用了rpcx
分包代码规范问题
我在我负责的集群模块下面分了好多模块，这造成了包管理的混乱（内部功能实现居然要将内部的用到的字段暴露）
网上搜索有关go分包的规范，发现这篇
Organize your code with Go packages — Master Tricks | by Inanc Gumus | Learn Go Programming
在我的cluster包下，不应该出现不同层次功能的包，要出现也应该是集群的不同实现的包
- Keep your packages small
- Put related packages into sub-directories
- Create your packages as related clusters
- Hide almost everything
- Depend on things that don’t change often
- Go has no sub-packages
- Put tests into the same directory
- Don’t put your code into ./src folders
- Don’t export from the main
- Smaller programs may not need many packages
Naming packages
- Use simple names
- Do not use double or more words in names
- Let the package path speaks for what the package does
- Don’t repeat the package names
- Use common abbreviations
- Avoid generic package names
- Do not use underscores or camel-casing（Just use lowercase letters）
- Note: Names can contain Unicode characters
几天后继续补充，由于之前是写Java的，所以很自然而然的就把Java那套给搬过来了。这里我就把模块和包弄混了，所以在一个项目里建了不同模块，实际上应该共用一个mod，这样有利于版本发布。而权限问题应该由包来解决
日志同步问题
由于我是用raft来实现分布式共识的，而在raft算法中日志同步是增量修改的，并不是修改状态。所以我需要对涉及到的操作进行定义，比如节点增加，增加的参数等等
元数据修改操作：
- 节点增加（还有分片信息）
- 节点删除（同时删除对应的分片）
- 分片增加
- 分片删除
GoDance是一款用go语言编写的分布式搜索引擎，同时也是一款分布式文档数据库。支持分布式搜索以及分布式存储功能，对外提供restful Api接口来操作GoDance。
GoDance整体采用主从架构，实现了Raft算法来保证元数据的一致，并有一系列机制比如tranlog、分片存储、分片迁移、故障转移等来保证集群的高可用和高拓展性；在存储方面，利用了段的思想来提升搜索和插入的性能，同时支持正排索引（B+树）和倒排索引（BST和MAP）来提升搜索能力，并自己实现了相应的数据结构和Linux系统上的持久化机制（MMAP）；在路由方面，根据索引内存负载率和机器配置会优先路由效率高的分片节点，同时使用了rpcx来进行rpc调用；在搜索方面，实现了TF-IDF等搜索算法，并利用其实现了相关度搜索。
如何去抽象操作不同类型的日志（日志增加）
- 类型嵌入
- 空接口，实现多种类型的数据结构
- 空接口字段定义操作参数（强制转换，接口+反射）
- 使用1.18新加入的泛型
Go 1.18 泛型全面讲解：一篇讲清泛型的全部 - SegmentFault 思否
仔细想了想发现自己的这个场景还是不太一样的，无法用泛型
最终使用类型断言和反射解决问题
如何实现Raft的日志一致性
可以理解为二阶段提交，但是有个问题——当确定是否要提交之前（等待那个大多数），是否允许提交新的日志
经过一番推演，我的结论是要的，这样可以保证领导者的日志都是最终状态，有利于跟随者向领导者同步日志，同时也是为了保证日志顺序的一致性
如何设计内存中的状态日志的数据结构
需求：
- 日志是一项一项递增的
- 日志存在未提交和提交两种状态，提交的数据需要更新到集群中的状态机中
- Leader的探活请求会携带当前最大的提交日志，跟随者需要根据此来提交之前的
节点删除策略
非主节点直接移除，非主节点保留该数据结构，修改其状态为Dead
go语言没有子包的概念，有点伤，自己写模块的时候会有点乱
go模块依赖问题
今天一早发现项目依赖爆红，跟我说reading tree note: note has no verifiable signatures
验证签名失败，搜了半天，大概明白是mod机制的验证问题，最后受不了了，干脆把pkg依赖全删了重新导，最后成功解决
后来搜索资料发现
大概是我某个依赖包被无意篡改了，或者官方同个版本的依赖包更新，hash变了。总之就是校验失败了
go的程序初始化问题
因为我负责的集群模块依赖配置模块的导入，所以在编写init方法是有一些顾虑
搜了下才发现
golang程序初始化先于main函数执行，由runtime进行初始化，初始化顺序如下：
- 初始化导入的包（包的初始化顺序并不是按导入顺序（“从上到下”）执行的，runtime需要解析包依赖关系，没有依赖的包最先初始化，与变量初始化依赖关系类似，参见golang变量的初始化）；
- 初始化包作用域的变量（该作用域的变量的初始化也并非按照“从上到下、从左到右”的顺序，runtime解析变量依赖关系，没有依赖的变量最先初始化，参见golang变量的初始化）；
- 执行包的init函数；
所以为了达到效果，config包尽量不要依赖于其他包
节点间自动发现的初始机制
raft算法解决的是分布式共识问题，利用一系列机制来确保日志的一致性。而最开始的节点发现问题并没有解决，所以我需要设计一种机制来促使初始节点的自动发现。
这里总体借鉴ES的设计思路，将集群节点分为Master节点和Data节点
Master节点可以参与Leader的竞选，Data节点主要参与数据存储，一个节点既可以是Master节点，也可以是Data节点，这可以在配置文件中cluster.master 和cluster.Data 进行配置。
为了使自动发现成为可能，我们加入了种子节点的概念，种子节点可以通过cluster.seedNodes进行配置，它是一个数组，每个字符串代表了一个可访问的节点地址。
在节点启动时，开启心跳检查，如果发现自己不在集群中，会向种子节点们发送rpc查询，获取当前的Leader节点地址。如果有Leader节点地址，说明现在已经有Leader，则向该Leader节点发JoinLeader RPC调用；否则则根据自己是否是Master节点来决定自己是否要参与竞选还是不断向种子节点获取当前Leader的地址。
PS：这里要注意就算是参与竞选也不能无脑一直参与，而是得判断自己是否在集群当中，如果不在，则意味着自己根本不在集群，人家根本不知道当前节点存在，所以在这种情况下，竞选失败需要尝试tryJoin的逻辑
- 成功选举，但是种子节点发送失败，这就意味着后期其他节点节点加入时，Leader永远是无法被发现
- 新增一个节点但是该节点没有在clients中就无法发送心跳
Leader删除一个节点同时需要把对应client给删除，同时sendHeart需要判定当前节点是否存在nodes中，如果不存在，则停止发送信息
集群模块的测试问题
在完成了集群模块的功能后，发现测试成了一个问题。
它不像普通的程序那样简单的测试方法，它主要有以下难点：
- 集群模块需要多台机器进行运行测试
- 集群模块中涉及大量的并发编程和网络调用
Raft算法问题思考
由于Raft算法比较复杂,看论文看的晕乎乎的,看网上资料质量又参差不齐,所以在理解这个算法的时候踩了很多坑。其中一个就是term对于选举的影响，当时我忽略了在拉票请求中节点无论投不投票都会更新为更大的term。所以在后面思考问题的时候绕了进去，发现了算法不成立的地方（其中一个节点因为网络延时开始竞选，但此时其他节点又接受到Leader的日志更新，根据不给日志完整性低的节点投票的原则，当前节点陷入无限选举的情况），当时还想着能不能竞选失败去重新尝试加入主节点等其他方案。
明白了term更新的机制也就解开了疑惑，但随之而来还有一些问题，当一个Follower节点仅仅因为网络延时导致开始竞选，那么必然会导致新一轮的竞选，因为term变大的，尽管这个Leader可能不是那个网络时延的节点，但肯定是最完整的节点，这样容易在
raft算法的局限： 1、强领导模型对于写功能基本退化单机性能，量大任然会出现性能瓶颈，适得其反。 2、选举期间会集群将出现短暂不可用现象，影响时长与选举时间相关。
日志完整性问题
如果新领导者不包含这部分日志，这部分日志会覆盖，即“以领导者日志为准，实现各节点日志的一致”，需要我们注意的是，复制到大多数节点的日志项，是不会丢失和改变的，而只被成功复制到少数节点的日志项，可能会被覆盖，也可能最终会被提交。
这里的大多数并不保证提交的大多数，所以在判断日志完整性时，我们不该以Committed的日志Id为标准，而应该以最新插入的日志Id为标准。
这里为了需要有个机制来保证新领导者有大多数的committed：
领导者选举能保证新领导者一定包含这条committed的日志项，但这条日志项在新领导者上处于未提交状态，这时新领导者，会尝试从最新日志项开始，向其他节点复制日志，如果，某条uncommitted的日志项，被发现已经成功复制到大多数节点上，这时这条日志项将处于提交状态，并被应用到状态机，通知其他节点提交这条日志。
此时集群会短暂不可用
如何理解“大多数”
集群配置不是随时变化的，需要按照一定的算法，比如联合共识、单节点变更，来添加和移除节点，也就是集群当前的节点数是已知的
采用哪种数据分片方式？
hash
一致性hash
range hash
function hash+range hash
最终还是参考MongoDB的分片方案——hashfunction+ hash range
分布式ID如何生成？
暂时采用UUID的解决方案
特征值如何选定？
特征值由用户选定