kratos

基于http2协议实现gossip协议

可以复用微服务的端口

基于UDP协议实现gossip协议

dns协议是基于UDP协议实现的，而gossip和dns都能实现服务发现，按理说gossip协议也能使用UDP协议

使用UDP协议的好处：

1. 低延时：UDP是一种无连接的协议，不需要在通信之前建立连接。
2. 简单性：UDP协议的设计相对简单，实现和解析容易，有助于减少服务器负载。
3. 无状态：gossip和DNS查询都是无状态的，UDP的无连接特性使得服务器可以同时处理多个查询，而不需要维护连接状态。
4. 较小的数据包：DNS查询(或者gossip请求)通常只包含几十个字节的数据，而UDP的最大传输单元(MTU)为64KB，这足够容纳大多数DNS查询(或者gossip请求)和响应。使用UDP可以避免TCP头部的额外开销。

一定要重写memberlist协议

memberlist使用的是Mozilla v2协议，和LGPL类似，不利于商业。

grpc vs mqtt

Q: 长连接是mqtt靠谱还是grpc靠谱 A: 长连接在MQTT和gRPC都是非常靠谱的通信方式，但是它们的用途略有不同。

MQTT协议是一种轻量级的消息传输协议，它被设计用于连接低带宽、不稳定网络的物联网设备。MQTT协议使用长连接，可以在设备和服务器之间建立一个可靠的、持久的通信通道，这个通道可以支持设备向服务器发布消息、订阅主题、接收推送消息等功能，可以确保消息的可靠传输。

gRPC是一种高性能、跨语言、开源的远程过程调用框架，它支持基于HTTP/2的双向流式通信，通过长连接实现高效的通信。gRPC可以在客户端和服务器之间建立一个长连接，使得客户端可以向服务器发送请求，并在同一个连接上接收响应。这个长连接可以重用，从而提高通信的效率。

因此，长连接在MQTT和gRPC中都是靠谱的通信方式，但是它们的应用场景略有不同，需要根据具体的需求进行选择。如果需要建立一个可靠的、持久的通信通道，用于物联网设备的消息传输，那么选择MQTT协议是比较合适的。如果需要高效的、跨语言的远程过程调用，那么选择gRPC是比较合适的。

Q: mqtt没有grpc高效么

A: MQTT和gRPC都是基于长连接的通信方式，它们在不同的应用场景下都可以实现高效的通信。

MQTT协议是一种轻量级的消息传输协议，它可以在低带宽、不稳定的网络环境下实现可靠的消息传输。MQTT协议的优点在于它的通信开销小、传输速度快、能够支持大规模的连接等。MQTT协议主要用于物联网领域，如传感器、监控、远程控制等领域。

gRPC是一种高效的远程过程调用框架，它基于HTTP/2协议，支持双向流式通信，可以实现高效的跨语言通信。gRPC的优点在于它具有高效的序列化、高速的网络传输、流式数据传输等特点，可以用于分布式系统、微服务等领域。

因此，MQTT和gRPC在不同的应用场景下都可以实现高效的通信，选择哪种协议取决于具体的应用需求。如果需要进行物联网设备的消息传输，那么选择MQTT是比较合适的；如果需要进行高效的跨语言远程过程调用，那么选择gRPC是比较合适的。

Q: 终端和服务端的通信，使用mqtt还是grpc呢 A: 终端和服务端的通信选择MQTT还是gRPC，需要根据具体的应用场景和需求进行选择。

MQTT协议是一种轻量级的消息传输协议，它主要用于物联网设备的通信。如果终端设备比较简单、处理能力有限，需要在低带宽、不稳定的网络环境下实现可靠的消息传输，那么选择MQTT是比较合适的。使用MQTT协议可以实现设备和服务器之间的消息传输、订阅主题、接收推送消息等功能，具有很好的灵活性和可靠性。

gRPC是一种高效的远程过程调用框架，它可以用于终端设备和服务器之间的通信，实现高效的跨语言远程过程调用。如果终端设备处理能力较强，需要进行复杂的计算和数据处理，那么选择gRPC是比较合适的。gRPC可以实现高效的序列化、高速的网络传输、流式数据传输等特点，适用于分布式系统、微服务等场景。

因此，如果终端设备比较简单，需要在低带宽、不稳定的网络环境下实现可靠的消息传输，那么选择MQTT协议是比较合适的。如果终端设备处理能力较强，需要进行复杂的计算和数据处理，那么选择gRPC是比较合适的。

Q: 介绍下mqtt协议 A: MQTT协议是一种轻量级的消息传输协议，通常用于物联网(IoT)领域的设备间通信。MQTT协议的特点在于协议头部信息小、可靠性高、支持低带宽网络和不稳定网络，适合于需要节省带宽和网络资源的应用场景。

MQTT协议的基本组成包括客户端(Client)、服务端(Server)和代理(Broker)三个部分。其中客户端可以是任何连接到代理的设备或者应用程序，服务端是承载代理的服务器，代理是实现消息转发、路由和存储的中间件。

MQTT协议的消息结构非常简单，包含两部分：固定头部和可变头部。固定头部包括消息类型、消息标志位等信息；可变头部包含会话ID、主题、QoS等信息。MQTT支持三种QoS级别，即QoS0、QoS1和QoS2，可以根据应用场景需求进行选择。

MQTT协议的优点在于通信开销小、传输速度快、能够支持大规模的连接等。它适用于低带宽、不稳定的网络环境下，可以保证消息的可靠传输。由于MQTT协议是基于发布-订阅模式的，具有很好的灵活性和可扩展性，可以广泛应用于物联网领域，如传感器、监控、远程控制等领域。

总的来说，MQTT协议是一种轻量级的、可靠的、灵活的消息传输协议，适用于物联网领域的设备间通信。

Q: mqtt协议格式 A: MQTT协议消息包含两个部分：固定头部和可变头部。固定头部包含消息类型、标志位和剩余长度等信息，它的长度是固定的；可变头部包含可变的信息，例如主题和QoS等级，它的长度根据消息类型和标志位的不同而变化。除了固定头部和可变头部之外，MQTT消息还可以包含负载(Payload)信息，即要传输的实际数据。

MQTT协议的消息格式如下：

   7                          0
 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  类型 |  标志位 | 剩余长度  |
 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        可变头部长度       |
 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          可变头部         |
 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            负载           |
 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中各字段的含义如下：

• 类型(Type)：表示MQTT消息的类型，占一个字节，取值范围为0~15。不同类型的消息在标志位和可变头部的格式和内容不同。

• 标志位(Flags)：表示消息的标志位，占一个字节。不同类型的消息的标志位的含义不同，用于指示消息的QoS级别、是否需要保留等信息。

• 剩余长度(Remaining Length)：表示剩余长度，占1~4个字节，用于表示整个MQTT消息的长度。

• 可变头部长度(Variable Header Length)：表示可变头部的长度，占2个字节。

• 可变头部(Variable Header)：包含消息的类型和标志位所需要的参数，例如主题和QoS等级等。

• 负载(Payload)：表示要传输的实际数据，长度可以为0。

在MQTT协议中，消息类型(Type)共分为16种，不同类型的消息在可变头部和负载上的内容和格式不同，包括连接请求、连接响应、订阅请求、发布消息等。

Q: grpc协议格式 A: gRPC协议的消息是基于HTTP/2协议传输的，它采用Protocol Buffers进行序列化，消息格式包括Header和Payload两部分。

Header部分包含四个元数据（Metadata）：Message Type、Compression、Request ID和Message Encoding。

Payload部分则包含了Message所需传输的信息，它采用Protocol Buffers进行序列化，包括方法名、请求参数、响应结果等信息。

具体来说，gRPC协议的消息格式如下：

+---------------------+----------------------+----------+
|       Header        |      Payload         |          |
+---------------------+----------------------+----------+
|    Message Type     |       Method         |  (optional)
+---------------------+----------------------+----------+
|     Compression     |     Request ID       |  (optional)
+---------------------+----------------------+----------+
|   Message Encoding  |      Payload Size    |          |
+---------------------+----------------------+----------+
|                                                 |
/                  Binary Payload                  /
/                                                 /
+-------------------------------------------------+

其中各字段的含义如下：

• Message Type：表示消息类型，占用1字节，用于标识该消息是请求还是响应等类型。
• Compression：表示是否使用压缩，占用1字节。
• Request ID：请求ID，占用4字节，用于区分不同的请求和响应。
• Message Encoding：表示Payload采用的序列化方式，占用1字节。
• Method：表示gRPC服务的方法名，长度不固定，占用字节数不定。
• Payload Size：表示Payload的大小，占用4个字节，用于接收方解析Payload。

在Payload部分，请求和响应的格式不同，但它们都是基于Protocol Buffers进行序列化的，具体内容可以根据业务需求进行定义。

ngossip

Q: nginx-upsync-module模块的原理 A: nginx-upsync-module是一个Nginx第三方模块，它可以与Nginx一起使用，用于实现负载均衡。它的原理是通过与Nginx配合使用，在Nginx运行时动态地更新后端服务器的列表，从而实现动态负载均衡。

具体来说，nginx-upsync-module模块的工作原理如下：

1. 启动时，nginx-upsync-module模块会从配置文件中读取后端服务器列表，并将其存储在内存中。

2. 当有新的后端服务器添加到列表中时，nginx-upsync-module模块会动态地将其添加到内存中的服务器列表中。

3. 当有后端服务器被删除或者出现故障时，nginx-upsync-module模块会动态地将其从内存中的服务器列表中删除或者标记为故障状态。

4. 当有客户端请求到达时，Nginx会根据内存中的服务器列表进行负载均衡，并将请求转发到某个后端服务器上。

5. 如果有后端服务器发生故障或者恢复正常，nginx-upsync-module模块会动态地更新内存中的服务器列表，以确保后端服务器的状态始终正确。

通过使用nginx-upsync-module模块，Nginx可以实现高效的负载均衡，同时也可以动态地更新后端服务器列表，从而确保系统的高可用性和稳定性。

Q: nginx编写gossip插件的思路 A: 要编写一个Gossip插件来扩展Nginx的功能，您可以按照以下思路进行：

1. 确定插件的功能和作用 首先，您需要确定插件的功能和作用，即它是用来实现什么功能的。例如，您可以考虑实现一个Nginx Gossip插件，用于节点之间的信息交换和数据同步。在此基础上，您需要考虑插件的实现方式和实现细节。

2. 学习Gossip协议的原理和机制 Gossip协议是分布式系统中广泛使用的一种协议，可以用于节点之间的信息交换和数据同步。在编写Gossip插件之前，您需要学习Gossip协议的原理和机制，了解它的工作方式和优缺点。

3. 学习Nginx的开发方式和API Nginx是一种高性能的Web服务器和反向代理服务器，它具有轻量级、高并发和高可靠性等优点。在编写Nginx插件时，您需要学习Nginx的开发方式和API，了解如何使用Nginx提供的API来实现插件的功能。

4. 实现Gossip插件 在学习完Gossip协议和Nginx开发方式之后，您可以开始实现Gossip插件了。具体来说，您需要按照以下步骤进行：

（1）定义插件的数据结构和状态机

（2）实现插件的初始化和清理函数

（3）实现插件的消息处理函数和状态转移函数

（4）将插件注册到Nginx中，并添加配置项

1. 测试和优化插件性能 完成插件的开发之后，您需要进行测试和优化插件的性能。具体来说，您可以使用一些工具和测试方法来测试插件的性能和稳定性，并对插件进行优化和调整，以提高其性能和稳定性。

以上是编写Nginx Gossip插件的一些思路和步骤，希望对您有所帮助。

Q: golang写的memberlist的原理 A: Memberlist是一个Golang编写的库，提供了一种轻量级的成员列表协议，可以用于分布式系统中的成员管理和协调。下面是Memberlist的工作原理：

1. 成员加入 Memberlist库的一个实例称为一个节点。当一个节点启动时，它会向网络中的其他节点发送一个JOIN请求，以请求加入集群。如果其他节点同意，它们将在自己的成员列表中添加该节点，并将自己的成员列表发送给该节点。该节点将自己的成员列表与其他节点的成员列表合并，并定期发送心跳消息以保持连接。

2. 成员离开 当一个节点离开集群时，它会向其他节点发送一个LEAVE请求，告知它们自己即将离开。其他节点将从自己的成员列表中移除该节点，并将自己的成员列表发送给其他节点。其他节点也会从它们的成员列表中移除该节点。

3. 成员失效 如果一个节点无法与其他节点通信，则它将被视为失效节点。其他节点将从自己的成员列表中移除该节点，并将自己的成员列表发送给其他节点。其他节点也会从它们的成员列表中移除该节点。

4. 成员列表同步 为了保持成员列表的一致性，Memberlist库使用了一种基于gossip协议的成员列表同步机制。每个节点将自己的成员列表定期发送给随机选择的其他节点。接收到成员列表的节点将与自己的成员列表进行合并，并将合并后的列表发送给其他节点。通过这种方式，整个集群的成员列表将逐渐保持一致。

5. 心跳检测 为了检测节点是否处于活动状态，Memberlist库使用了一种基于心跳的机制。每个节点会定期发送心跳消息给其他节点，如果一段时间内没有收到其他节点的心跳消息，则该节点将被视为失效节点。

以上是Memberlist的工作原理，它可以提供一种简单且高效的成员管理和协调机制，适用于分布式系统中的各种场景。

Q: SWIM和gossip协议的区别 A: SWIM（Scalable Weakly-consistent Infection-style Process Group Membership Protocol）和gossip协议都是用于分布式系统中的成员管理和协调的协议，它们之间的区别如下：

协议类型 SWIM是基于ping-ack机制的可扩展成员协议，而gossip协议是基于概率采样的广播协议。

成员列表同步 SWIM协议通过ping-ack机制和直接反馈来实现成员列表同步，而gossip协议则是通过选择随机节点进行信息交换来实现成员列表同步。SWIM的同步效率较高，但会产生较多的网络流量，而gossip的同步效率较低，但网络流量较小。

节点状态管理 SWIM协议通过主动检测其他节点状态来判断节点是否失效，而gossip协议则是通过被动接收其他节点的状态信息来判断节点是否失效。SWIM协议可以更快地检测到节点失效，但会产生更多的网络流量。

适用场景 SWIM协议适用于大规模分布式系统，能够有效地处理成千上万个节点的情况。而gossip协议则适用于中小规模的分布式系统，能够在节点数较少的情况下提供较高的同步效率和可靠性。

综上所述，SWIM协议和gossip协议都有各自的优势和适用场景，选择哪种协议取决于具体的应用场景和需求。

Q: redis中的gossip的实现 A: Redis使用了基于gossip协议的集群管理机制，称为Redis Cluster。Redis Cluster中每个节点都是对等的，每个节点都可以接收客户端请求，并且具有自动发现和故障转移的功能。

Redis Cluster通过gossip协议来实现节点之间的信息交换和状态同步。每个节点都维护着一个关于集群拓扑结构的视图，并定期通过gossip协议向随机选择的其他节点发送自己的视图，同时接收来自其他节点的视图信息。当节点发现自己的视图与其他节点的视图不一致时，会进行重新平衡，选择新的主节点来保持集群的一致性。

Redis Cluster中每个节点都有自己的角色，包括主节点和从节点。主节点负责处理客户端的读写请求，并对数据进行复制和同步，从节点则负责对主节点进行数据复制和同步，并在主节点失效时自动接管主节点的角色。

通过gossip协议，Redis Cluster能够自动发现新加入的节点、发现节点失效、平衡集群负载等。同时，Redis Cluster还提供了故障转移的功能，当主节点失效时，系统会自动选举新的主节点，并进行数据复制和同步，保证了数据的可靠性和高可用性。

2pc，Two phase commit

二阶段提交协议，就是将事务流程分成准备阶段（Prepare）和提交阶段（Commit），用于保证事务执行时数据的强一致性。

一个最被人熟知的二阶段提交就是MySQL redo log 和 binlog。由于InnoDb存储引擎使用B+tree作为底层索引结构，在写入数据时无法保证顺序写入，因此引入了redo log作为WAL，用于提高数据的写入效率。同时 MySQL 使用 binlog 这一逻辑日志实现数据的复制与灾难恢复。redo log 和 binlog 属于不同的文件，在事务执行时，既要写 redo log，又要写 binlog， 那么如何保证这两个文件中数据的一致性就是 2PC 需要解决的问题。

            +----------------+
一阶段提交  | write redo log |
            |   (prepare)    |
            +----------------+
                    v             ->  may crash
            +----------------+
            |  write binlog  |
            +----------------+
                    v             ->  may crash
            +----------------+
二阶段提交  |    提交事务    |
            |   (committed)  |
            +----------------+

1. redo log之后、binlog之前崩溃。 此时未写入 binlog， redo log 也没有提交，因此崩溃恢复之后InnoDB会回滚该事务，并且由于binlog中没有这部分的数据，所以从库也不会有该事务的数据

2. binlog之后、commited之前崩溃。 此时binlog数据完整，那么在崩溃恢复之后 InnoDB 会提交该事务。此时不管是使用异步复制还是半同步复制，从库都会收到该事务的数据并重放，主从之间的数据是一致的

一个通用的2PC模型：

                      一阶段       |        二阶段
               提出     同意       | commit  committed
[coordinator]----+------+----------|----+------+--------------------------------------------------------
                 |      |          |    |      |
               +-+-+  +-+-+        |  +-+-+  +-+-+
               | | |  | | |        |  | | |  | | |
               v | |  ^ | |        |  v | |  ^ | |
[voter-1    ]--+------+------------|--+------+----------------------------------
                 v |    ^ |        |    v |    ^ |
[voter-2    ]----+------+----------|----+------+--------------------------------
                   v      ^        |      v      ^
[voter-3    ]------+------+--------|------+------+------------------------------

将 voter 替换成集群中对应的节点即可。

在Raft等共识算法中，一阶段和二阶段只需要得到超过半数节点的成功即可。
而在分布式事务中，则必须得到全部节点的同意，否则就会出现数据的不一致。

什么是共识问题（拜占庭问题）？

我们在新闻上能经常听到这样的报道，我国与 XXX 就 XXX 方面达成了共识，共识其实就是对某一事情的看法达成一致。比如我和小明相约周末一起去钓鱼，小明同意了，那么我和小明就在钓鱼这件事情上达成了共识。

我们以李云龙、孔捷和丁伟攻打平安县城为例，将拜占庭问题本土化。李云龙、孔捷和丁伟一起攻打平安县城，并且李云龙没有意大利炮。同时，必须有两只部队一起攻打平安县城，才能成功。李云龙、孔捷和丁伟的部队分别驻扎在平安县城的3个方向，所以部队之间只能通过信使相互联系。 并且，信使在送信的路上可能被杀，也可能被敌人的间谍渗透，传递假消息扰乱正常的作战计划。3位指挥官分别向其他两名指挥官传递进攻或者是撤退的消息，指挥官收到消息后，按照“少数服从多数”的方式来进行决策。

       [ 李云龙]
      /^      ^\
 进攻//        \\进攻
    //撤退  进攻\\
   v/            \v
  +----+ 撤退   +----+
  |丁伟|------->|孔捷|
  +----+<-------+----+
         进攻

在正常情况下，上面的方式能够有效的组织进攻/撤退计划，3只部队要么一起进攻，要么一起撤退。但是，假如说李云龙的信使被敌军渗透了，向丁伟和孔捷传递了错误的消息，又会出现什么情况呢？


        [ 李云龙]
       /^      ^\
chetui//        \\chetui
     //撤退  进攻\\
    v/            \v
  +----+ 撤退   +----+
  |丁伟|------->|孔捷|
  +----+<-------+----+
         进攻

被敌军渗透的信使向丁伟和孔捷传递了错误的撤退信息，导致李云龙认为有2票进攻、1票撤退，而丁伟和孔捷均有2票撤退和1票进攻。这会导致只有李云龙的部队去攻打平安县城，导致伤亡惨重。

实际上这就是“两忠一叛”问题，在&#x2029;3 位指挥官中如果出现了&#x2029;1 个叛徒，那么这&#x2029;3 个人是无法达成共识的，叛变的那个人总是能够想办法干扰到最终的决定

签名消息型解决方案: 这种解决方式就比较简单了，采用对消息加密且篡改后会被发现的方式来进行消息传递。那么一旦指挥官接收到了被篡改的信息，将会直接忽略掉此信息。若进攻和撤退的票数相同的话，只需要约定一下在此情况下是进攻还是撤退即可

口信消息型解决方案：

在口信消息型解决方案中，首先发送消息的指挥官称为施令官，其他指挥官为副官。对于3忠1叛的场景需要进行两轮作战信息协商，如果没有收到作战信息那么默认撤退。

流程: 
1. 在第一轮讨论中，我们随机地选取一个施令官，不管这是施令官是忠诚的还是叛徒，然后这个施令官向其他指挥官下达命令
2. 除了第一轮的施令官以外，剩余的3位指挥官分别向另外两名指挥官发送作战信息，而这个信息其实就是施令官在第一轮告诉当前指挥官的。最后，3位指挥官按照“少数服从多数”，执行相应的作战计划。


场景一， 信使被渗透
        [  赵刚  ]
            v
    +-------+---------+
  进攻     进攻     进攻
    v       v         v
[丁伟]   [李云龙]   [孔捷]


        [ 李云龙]
       /^      ^\
chetui//        \\chetui
     //进攻  进攻\\
    v/            \v
  +----+ 进攻   +----+
  |丁伟|------->|孔捷|
  +----+<-------+----+
         进攻

此时，即使是李云龙的信使向其它指挥官发送了错误的信息，最终的票数还是决定了丁伟和孔捷将会发起攻击，3 位指挥官达成共识


场景二，施令官被渗透

假设赵刚被敌军渗透了，向李云龙下达了错误的进攻信息，但是在第二轮信息共享时，由于丁伟和孔捷收到的都是撤退信
息，最终李云龙部队也不会向平安县城发动总攻，3 名指挥官仍然能达成一致

        [  赵刚  ]
            v
    +-------+---------+
  撤退    jingong    撤退
    v       v         v
[丁伟]   [李云龙]   [孔捷]


         [ 李云龙]
        /^      ^\
jingong//        \\jingong
      //撤退  撤退\\
     v/            \v
  +----+ 撤退   +----+
  |丁伟|------->|孔捷|
  +----+<-------+----+
         撤退

Lamport 在论文中论证了假设有
m 名叛军，那么将军总人数不能少于
3m
+
1，否则无法使用口信消息型解决方案来解决拜占庭将军问题

分类：

1. 拜占庭容错算法 可以解决分布式系统中既存在故障，又存在恶意攻击场景下的共识问题，最为经典的应用就是区块链的PoW算法

2. 非拜占庭容错算法 解决的是分布式系统中存在故障，但不存在恶意攻击的场景下的共识问题。多用于分布式数据库中，比如Raft算法

CAP理论

只要涉及到网络通信，那么就会发生网络波动、高延迟、数据丢失等情况，即分区故障必须考虑

1. 对于
CP 模型来说，放弃了可用性，选择了一致性，适用于对数据一致性要求非常高的场景，例如金融业务、Kubernetes 集群中的资源信息等。使用
Raft 协议实现的金融级
MySQL 集群、etcd 或者
Consul 等，都可以认为是
CP 模型

2. 对于
AP 模型来说，放弃了强一致性，使用最终一致性来保证数据的最终一致，适用于一致性要求不高的场景，例如
CDN
 缓存、DNS 缓存等