IcyFenix
IcyFenix
> @Codier > 感谢作者的详细解释。 你提到ZAB, Multi Paxos和Raft是等价的算法（解决同样问题），但是他们的区别到底在哪里？ 核心原理都是一样：通过随机超时来实现无活锁的选主过程，通过主节点来发起写操作，通过心跳来检测存活性，通过Quorum机制来保证一致性。 具体细节上可以有差异：譬如是全部节点都能参与选主，还是部分节点能参与，譬如Quorum中是众生平等还是各自带有权重，譬如该怎样表示值的方式，等等。
@dengchaoh > 具体情况分析的情况一， “假设是S3，那么S3提供的Promise中必将包含S1已设定好的值X”，周大哥，应该是S3提供的Accept吧？ > 另外应答中返回的值是这样定义的"不违背以前作出的承诺的前提下，回复已经批准过的提案中ID最大的那个提案所设定的值和提案ID，如果该值从来没有被任何提案设定过，则返回空值。",情况一S3的提案是不是首次设置值？是的话，S3收到的Accept中的值是不是应该是null？如果不是首次设置值，是不是批准过最大提案ID对应的值呢，而不是返回S3本次提案的值X？ 是Promise。按照场景假设，S5是提案节点，S3是决策节点，提案节点会发出Prepare和Accept请求，决策节点会响应Promise和Accepted应答。可见S3是不可能发出Accept消息的。 只关注S1、S3、S5的之间的交互，此场景的时间线顺序如下： 1. S1向S3提交Prepare(3.5)的请求 2. S3向S1返回Promise(3.5,null)的响应 3. S1收到Promise(3.5,null)后，提交Accept(3.5,X)的请求 4. S3收到Accept(3.5,X)后，向S5返回Accepted(3.5,X)的响应 5. S5向S3提交Prepare(4.5)的请求 6. S3收到后发现已有设置值X，向S5返回Promise(4.5,X)的响应 7. S5收到Promise(4.5,X)后，无条件接受X代替原本的Y作为自己的提案值，提交Accept(4.5,X)的请求 8. S3收到Accept(4.5,X)后，向S5返回Accepted(4.5,X)的响应
> @bigbenfather > 情况二中有一句“譬如图6-3所示，S5发起提案的Prepare请求时，X并未获得多数派批准，但由于S3已经批准的关系，最终共识的结果仍然是X。”，这么说来，值一旦设定，就不能修改了吗？ 文中有写： > 值一旦设置成功，就是**不会丢失也不可变**的。请注意，Paxos是典型的基于操作转移模型而非状态转移模型来设计的算法，这里的“设置值”不要类比成程序中变量赋值操作，应该类比成日志记录操作
> @LebronAl > state tranfer 的定义应该是直接传内存磁盘里的数据来保证不同机器间的一致性吧，可以参考[6.824 课程第四讲 vmware fault tolerant 第 8-11 分钟](https://www.bilibili.com/video/BV1R7411t71W?p=4)的讲授内容。 > mysql cluster 基于 binlog 的主从同步方式实际上也是基于 RSM 吧，即假设应用相同顺序的日志能够保证不同节点上的 mysql 实例达到相同状态？ State Tranfer的核心思想是“当状态发生变化后，应在主、从状态同步一致之后再接受新的外部输入”，这个思想就是文中例子“手工复制文件到几块备份硬盘”背后的逻辑。 Robert Morris教授在课程中的举例是“主内存中的数据变化了，将完整的拷贝复制到备份节点，备份节点保留完整的状态”。从内存中复制数据这是一个具体的例子，如同文中举例的将硬盘中的数据复制到其他硬盘，不应该将它当作是State Tranfer的定义来理解。 Operation Transfer（State...
> @LebronAl > > State Tranfer 的核心思想是“当状态发生变化后，应在主、从状态同步一致之后再接受新的外部输入” > > 这个定义有可参考的文献吗？我查了一些文献，感觉学术界对此概念的定义似乎更多的是“当状态发生变化后，主、从状态同步一致的方式”这一出发点来说的，比如直接传内存的数据，或者类似于 raft 的 state machine 的 snapshot 等等，总之都是直接传输状态（应用层状态或者硬件状态均可）而不是需要重放的 operations。 State Transfer传输的当然是状态而不是操作序列，这点确凿无疑，不然也不会选择叫State Transfer这个名字。 我那句话的关键词是“**同步一致之后**再接受新输入”，这是它与Operation Transfer的核心区别，Operation Transfer是持续接受操作序列，以此重演历史来达成一致，这种复制并不要求同步的，这点也是State Transfer通常效率不佳的根源所在。 此前你引用的MIT课程中，Robert Morris教授的看法是：The idea behind state...
> @JerryQiang > 150人参与的项目，沟通成本大约是5个人时的一千倍 感谢，已更正，我的中学数学老师应该对我很不满意。
> 譬如下界的完备性要求微服务至少包含一项完整的（服）务 感谢，已更正。
> @yanyuyouyou > >为了解决LFU不便于处理随时间变化的热度变化问题，LFU采用了基于“滑动时间窗”（在“流量控制”中我们会更详细地介绍这种算法）的热度衰减算法 > > 这里应该是：TinyLFU采用了基于“滑动时间窗”的热度衰减算法 感谢指正，已修改。
> “引用方式：支持将数据设置为软引用或者弱应用”中的“弱应用”应该是“弱引用”吧？ 感谢
> @dengchaoh > PID 隔离进程编号，无法看到其他名称空间中的PID，意味着无法其他进程产生影响 > 周大哥，最后半句缺了个“对”，意味着无法“对”其他进程产生影响 谢谢，已经修正，下次commit时更新。