- 2019-04-26微信朋友圈评论主要由评论和后续回复组成：
首先，对于评论，评论内容对评论者而言应该要保证读写一致性（read-your-writes consistency），即评论一旦发出，那么对于该评论者无论在手机、网页还是其它城市应该都能看到其之前写的评论。而对于朋友圈可见的其它人来说，只要保证最终一致性（eventual consistency）就可以了（可能有时间要求），不同人的评论读取顺序无需和真实发生的顺序保持一致；
其次，对于评论的后续回复。回复内容对于回复者而言应该要保证读写一致性（read-your-writes consistency），而其它朋友圈可见的人一样，评论和回复内容应该按顺序被读取到，即需要保证一致前缀读（Consisten Prefix Reads） 29 
2019-04-26老师，我不太明白弱一致性和最终一致性的区别在哪里，文章对弱一致性提到
“经过不一致时间窗口这段时间后，后续对该数据的读取都是更新后的值”
这句描述的不就是最终一致性么
是不是说弱一致性允许数据始终不一致，而要求最终结果一致的弱一执性叫做最终一致性作者回复: 你好，这是个很棒的问题。简而言之，弱一致性是个很宽泛的概念，它是区别于强一致性而定义的。广义上讲，任何不是强一致的，而又有某种同步性的分布式系统，我们都可以说它是弱一致的。而最终一致性是弱一致性的一个特例，而且是最常被各种分布式系统用到的一个特例。其他的比如因果一致性、FIFO一致性等都可以看作是弱一致性的特例，不同弱一致性只是对数据不同步的容忍程度不同，但是经过一段时间，所有节点的数据都要求要一致。
学习时也没必要抠字眼，重要的是理解它们的区别。这部分知识是为了后边讲CAP理论服务的，实际的工作中不会像考试考概念题一样让你背写这些一致性的定义。
如果你还有疑问，欢迎继续留言。 24
2019-04-26朋友圈保证最终一致性即可，消息发布后，先保证“端”是可见的，等待网络请求后会确认最终有无发布成功，成功后最终其他人的timeline会收到作者回复: 你的想法很好，但是有的场景下最终一致性还不够。试想这个场景，A发布了一张图片，B问他这是哪里，然后C回答B这里是北京。这个例子中，C的评论一定要在B之后，因为他俩有逻辑上的因果关系。所以微信朋友圈的评论要满足这样的因果一致性。因果一致性也是弱一致性的一个特例，感兴趣的话可以去多搜索点资料来学习～
8
2019-04-30老师我想问一下，所谓的强一致性，它允许的误差是多少范围？
比如金融股票大厅显示屏数据，应该是强一致性的吧，全球显示误差不会超过0.2s吧？
这样强一致性怎达到？网络传输，路由处理都不止了，更何况还有网络延迟作者回复: 谢谢你的提问！强一致性并没有误差可言的，强一致性简单地说指的就是如果更新一条数据，那所有用户读取数据的时候必须都看到这条更新了的数据。
在这里我也分享一个自己的面试经历。其实这个问题恰好我当年在面试Bloomberg的时候面到过，是一道系统设计题。问的大概是在设计他们家股票信息系统的时候，数据的更新写入量太大，用户也需要读取最新的股票资讯，该如何设计这套系统。最后和它家的tech lead讨论发现，原来他们的股票系统显示的延迟范围是1分钟左右，因为应用场景上普通股民并不会需要实时关心每秒钟股票价格的动态，更多的是关心大盘走势。而金融巨头在操作股票的时候更多只关心特定的几只股票，所以这些股票的价格通常对于他们来说会更新快一点。
所以说金融股票大厅上的数据应该不会是强一致性的，延时误差也应该没有你想象的那么少。 1 4
2019-04-26恩~其实我好像没有听懂~介绍了几个概念的定义，但还是不理解它们之间的联系和差别。 4
2019-05-06老师，消息队列的持久性第二点不是太能理解，意思是说消息发送者发完消息后，接收者下线了，然后接收者上线仍能收到吗？作者回复: 谢谢你的提问！没错，这里的持久性指的就是消息队列在接收到发送者发送的消息后，只要没有收到接收者的回应，就会一直尝试发送消息给接收者，直到收到回应为止。所以接收者下线了再上线仍是能收到消息队列发送的消息。当然中间如果超过了消息保留期限或者一定的重发次数也会消息队列也会停止发送。
3
2019-04-26笔记总结：扩展性包括水平和垂直，水平扩展是增加水平类似的机器打群架方式，垂直扩展是现有的每个人提升实力，提升整体实力；一致性，集群上的数据为了保证高可用性显然要存在不同机器上存多份，这就存在不同机器数量同步问题，要求同步造成才可以进行读写的就是最终一致性，中间准许有个不一致时间窗的就是弱一致性，时间窗更长但是最终会统一的就是最终一致性，比如发微博场景，还讲了数据持久性，消息的持久性，一般类似kafka之类消息总线系统可以配置各种持久性要求，比如要求所有主和副本都同步，要求只要发给主即可，有的发送不需要确认。
关于问题：朋友圈属于最终一致性，信息推送晚一会不是特别重要，所以最终一致性满足要求作者回复: 很棒的总结。
对于思考题的答案，建议你再读读别的读者得留言，有的留言思考很深入～ 3
2019-04-26ap模型，先保证评论的人自己能看见，再保证被评论的人和别人能看见。 3
2019-04-28朋友圈采用最终一致性+因果一致性就好，只要保证评论及其派生评论是有序的，以保证其逻辑、语义上面不会出现混乱，场景对延时性要求不高；另外，有注意到手机端的微信和PC端的微信，会出现数据不一致的情况（特别是微信公众号订阅的文章，PC端少些文章） 2
2019-04-27对于微信朋友圈的评论功能我想最终一致性，保护因果一致性的特征就够了。从需求角度，微信朋友圈是一种社交工具，不具有critical的特性，数据一致的实效性要求不高。每个独立评论的先后顺序也不那么重要。重要的是对于某一条评论的评论必须显示在派生这条评论的原始评论之后，否则用户读起来会很混乱。从最低成本满足需求的角度，因此最终一致性加上因果一致性特征即可。 2
2019-04-26弱一致性，场景可以容忍一定时间的延迟。 2
2019-05-02这一节课，怎么让我想起了阿里李云华＜从零到架构师＞中提到的CAP理论，这大规模数据和架构师之间的知识看来是想通的着呀作者回复: 谢谢你的留言！有同感，其实当你学识更广之后会发现计算机中很多方向都是相辅相成的，并不会说某一块知识是相对独立起来的。
1- 2019-04-26因果一致性。比如说A评论了，然后B评论了A的评论，只要保证A的评论在B对于A的评论之前就行了。 1
- 2019-04-26以前曾经考虑过微信朋友圈这个一致性问题，最初认为是顺序一致性，仔细一想，如果是顺序一致性，成本太高，也没必要，对于微信朋友圈的评论来说，只有互为好友的人才能看到，评论也是互为好友的人，如果A发了朋友圈，所有人对A的评论，只有A才能完全看到，同时，B对A如果进行了评论，C对B的评论进行了评论，那么，对于A,B,C来说，C的评论肯定在B之后，只要保证互相能看到的评论一致即可，所以应该是因果一致性，至于如何的，暂时还没考虑 1
2019-04-26我觉得微信朋友圈只要最终一致就够了，没有对更新延迟那么高的要求 1- 2019-04-26我想请教老师，有些业务，不用关系数据库的话，如果处理分析需求(OLAP)?就我所知连google这样的公司某些时候还是必须用join来完成一些数据分析。比如下面这类需求，分布式系统里，用户表和订单表在不同的库里。请查出所有20-30岁用户的订单，并按照一定的规则进行数据统计。而20-30岁的用户数量可能非常庞大，十几万之多，这类的需求。非关系型的数据库，或者分布式系统如何做统计？统计现在才是大部分公司实施分布式数据处理的困难点，相反事务倒不是那么重要了，互联网企业的需求对强一致性要求没那么高 1
2019-06-13思考题的评论系统，最终一致性比较合适，强一致的高延迟会非常影响用户评论的兴致- 2019-06-13为了提高系统的吞吐量，我们需要水平扩展。
水平扩展后，消息，数据在集群中的传输，需要可靠的一致性保证。由于是分布式，无法保证像单机一样的强一致，只能保证最终一致性
分布式集群中，可能涉及通过通信沟通，去保证最终一致性，但通信可能会丢失。要么通过算法去保证，即便通信丢失，集群也能协商出一个一致的结果，比如paxos和raft算法。要么通过可靠的消息中间件来保证消息的可靠传达和消费。 
2019-05-09看老师评论里说需要最终一致性和因果一致性，感觉这个因果一致性和Java内存模型里的happens-before好像作者回复: 谢谢你的留言！是的呢，在第九讲里面所讲到的线性一致性（Linearizability）其实也和Java Memory Model有关。如果在Java中修改的变量是volatile的话就会有这种线性一致性。
2019-05-02对于想深入学习分布式系统，有什么学习资料推荐的吗？