2019-05-03盆友圈适合使用pub/sub模式
原因1：消息发送方需要向多个接收方（n个可以看自己盆友圈的好友）广播消息
原因2：多消费者组（微信朋友圈数据应该不仅仅只是用于社交，可能还有其他作用吧，所以可能会有多个模块需要用到这份数据）
原因3：发送方发送消息之后是不需要接收方立即进行响应的（异步），所以用消息队列可以有效起到解耦的作用
原因4：微信朋友圈对于数据而言，满足最终一致性的作者回复: 谢谢你的答案，观点基本我都是赞同的！
2 18
2019-05-03老师，当今有许多很好的开源MQ，响Kafka，RabbitMQ等等，但是在看许多技术分享大会，为什么许多公司还会自己开发MQ呢？作者回复: 谢谢你的留言提问！个人觉得即便公司会开发自己的MQ，很多都是建立在这些开源项目之上的。一方面可能因为开源项目的一些属性并不能满足到自身的应用场景，所以加以改进。另一方面如果是大厂的话，可以打造出自己的一套生态圈，开发接口更加适合内部使用。
10
2019-05-05感觉没啥内容啊作者回复: 哈哈哈，感觉你的基本功很扎实啊，那这一讲你可以当作是复习章节，当然也可以留言和我讨论更高级的内容。我的专栏也希望能对初学者友好一点，对于初学者来说，这一讲是全新的内容呢。
9
2019-05-051. 微博粉丝订阅机制
由于存在流量明星，针对不同情况的用户，系统可以区别对待，在线用户采用“推”模式，尽量及时更新订阅者的timeline；不在线的用户采用“拉”模式，在该用户上线后更新timeline。
2. 微信朋友圈机制
由于不太可能存在微博这种超级发布者，因此可仅采用“推”模式。
3. 两款产品的共同点
a) 发布者必须实时同步处理，因为发布成功后需要直接看到自己生产的消息。
b) 订阅者可以异步处理，只要保证系统满足最终一致性即可。展开作者回复: 谢谢你的留言！总结得很到位啊！
9
2019-05-03老师好，有一点模糊的地方，请问观察者模式和发布/订阅模式的区别从消息的传递上来看就是是否通过消息队列传递数据么？另外消息队列是对接收者push消息还是接收者主动从消息队列中pull消息出来呢？谢谢老师作者回复: 你好呀，感谢你的提问！
其实在观察者模式下，你也可以通过消息队列去传递消息。但是更本质的区别是在观察者模式下，观察者必须知道被监听者的存在。就像例子所示，观察者必须调用被监听者的接口。而发布/订阅模式下，两者是解耦的，互相都不用知道对方的存在。
消息队列中既可以使用push模式也可以使用pull模式，关键在于应用场景的考虑。例如如果消息跟新发布频繁，而下游的接收者能够处理的qps不高，那可能会更加倾向于采取pull模式。 1 9
2019-05-06log offset类似tcp的滑动窗口机制，有个问题：如例子讲的10003，在第一次由于某种原因未被消费者消费，生产者又发了一次10003，然后第一次发送的10003又到了消费者，那么10003会被消费者消费两次，这种情况kafka会有什么处理机制吗？作者回复: 谢谢你的留言提问！一般来说，这种发送机制叫做at least once delivery，这种情况需要消费者自身具备Idempotency，也就是幂等性。消费者需要自己知道哪些消息是duplicate的，从而知道怎么处理这些重复消息。
1 4
2019-05-03微信朋友圈适合用消息发布－订阅模式
1.系统的发送方需要向大量的接收方广播消息。一个人打朋友圈，需要向有好友关系的多方发消息
2.朋友圈的数据会被多个独立的业务方使用，比如做数据分析用于投放朋友圈广告，进行用户行为分析，构建用户画像
3.系统的发送方在向接收方发送消息之后无需接收方进行实时响应。因为朋友圈这种业务应该使用pull模式，当A发朋友圈时，A的好友B C D，只有当B C D进行刷新朋友圈时，会去pull数据
4.朋友圈对数据一致性只会要求最终一致性
所以朋友圈很适合消息发布－订阅模式展开作者回复: 谢谢你的答案！分析得很详细，基本上我都是赞同的！
4- 2019-07-27如果微信朋友圈使用发布订阅模式的话，那么是不是意味着每一个用户对应一个消息队列呢，那这样的话是不是就得有好几亿消息队列？
作者回复: 谢谢你的提问！这个看你的设计了，即便真的使用发布订阅模式的话，同一个队列的消费者可以通过设置filter来只接收自己感兴趣的内容。
1 2 
2019-07-05請問老師 如果想把Oracle的數據實時同步到其他的地方比如MongoDB 要求幾秒鐘以內的latency 有沒有辦法使用pubsub的概念做到呢 又該如何做呢 謝謝作者回复: 谢谢你的提问！这个问题挺常见的，PubSub肯定是可以做到的。具体的做法还是看你的架构吧。如果你是own整一套系统的话，一种做法是你的service直接对这两个数据库进行dual write。如果你只是own这两个database的话，我相信Oracle应该是有一些database change notification的机制，这个时候你可以将这个data change publish到一个service中，然后再做同步。
2
2019-05-09如果接收方读取数据之后回应消息队列它接收的 Log offset 是 10000、10001 和 10003，那么消息队列就会认为接收方最多只接收了消息 10000 和 10001，剩下的消息 10002、10003 和 10004 则会继续发送给接收方，直到接收方回应接收了消息 10002、10003 和 10004。
第一句接收的log offset有10003吗？作者回复: 谢谢你的提问！如果我没理解错你的问题的话，你是想问接收方是否回复了10000、10001和10003这三个Log offset对吧？是的，接收的log offset有10003。因为消息队列需要接收到连续的log offset才会判定接收方接收到消息，这里因为log offset从10002断开了，所以消息队列会认为接收方从10002开始往后的消息都没有接收到。
1 2
2019-05-04老师好，对于消息队列中的消息存储有一个问题。在一个发布订阅模式下的消息队列中消息会被保存多久呢?具体情景是如果有五个接收方订阅了一个队列的消息，其中四个成功接收了，第五个总也无法接收，这条消息会一直保存在队列中，并且不断尝试发给第五个订阅者吗？还是会设置最多重复次数?另一个情景，在发布者发送消息至队列后，新增加了一个订阅者，这时新的订阅者可以收到队列里已放入的消息吗？谢谢。作者回复: 涵你好，谢谢你的留言与提问！
第一个问题，一般不同的系统有不同的机制去确定消息队列中消息会被保存多久。像Apache Kafka中可以通过设定Retention Period来确定消息被保存多久，甚至可以设置Retention Period为Forever来永久保存。
第二个问题，只要没有超过保留期，消息会一直保存在队列并且一直尝试发送给第五个订阅者。当然订阅者也可以自己设定retry times，如果第五个订阅者告诉消息队列只需要重试一次，那这条消息就不会再发送给第五个订阅者了。如果你要保证操作一定成功，就要考虑用RPC来调用了。
第三个问题还是要看系统设计了，设计上收到与不收到都可以做到，像Apache Kafka可以通过重设Log Offset的位置去实现新的订阅者收取队列里面旧的消息。如果你使用开源项目的话，文档里应该会有说明的。 2- 2019-05-03适合，1. 场景对实时性要求不高；2. 用户自己可以刷新拉取；
作者回复: 谢谢你的答案！
2 
2019-05-03老师您好，个人理解，观察者模式本质上是消息推出，订阅该消息的对象获取消息并进行处理；所以我认为，发布/订阅模式其实是一种特殊的观察者模式，或者是观察者模式的实现方式。作者回复: 谢谢你的留言！我觉得本质上还是有所不同的，毕竟在观察者模式中观察者需要知道被监听的对象，而发布/订阅模式通过消息队列解耦了这一层关系。
2
2020-01-13作为小白，这门课程真的很有帮助！
2019-08-04老师好!
"发布 / 订阅模式指的是消息的发送方可以将消息异步地发送给一个系统中不同组件，而无需知道接收方是谁。" => 那麽BROWSER探访网站伺服器这个情况, 算不算发布 / 订阅模式?- 2019-07-05有顺序的
2019-07-02文中提到kafka的log offset的例子，应该是争对某个topic下的partition吧？不是说整个topic吧？一个topic下会有多个partition，每个partition都有各自的log offset
2019-06-29学习心得：
消息队列有2个重点：
1. 解耦合——vs. 观察者模式实现相同效果，而且每次都要和观察者协商消息格式）
2. 高伸缩性——消息队列可以作为一个“独立”的“分布式存储”，专业团队维护。
apache kafka: Producer -> topics -> Consumer
发布/订阅模式限制：
1. 发送之后，无法做到接收方实时响应；
2. 只能满足“最终一致性，不能满足强一致性” （知乎有篇文章很好：https://zhuanlan.zhihu.com/p/67949045）展开作者回复: 谢谢你的留言和分享！总结得不错啊！
- 2019-06-23我上交学长就是厉害 课程形象生动 易于理解！
指出一个小typo，
“在了解了消息和消息队列后，现在我想和你正式地向你介绍...”
应为
“在了解了消息和消息队列后，现在我想和你正式地介绍...”
或者
“在了解了消息和消息队列后，现在我想正式地向你介绍...”展开作者回复: 啊哈哈，谢谢你的支持啊，同时也谢谢你的建议！
- 2019-06-22消息队列用于解耦多个系统之间的通信。特别是一对多的通信。假设a系统要发消息给b和c 如果没有消息队列，a系统需要实现对b和c发送的机制，考虑消息丢失的问题，考虑消息过大时的并发和容错问题。
引入消息队列后，a只需跟消息队列大交道，消息队列一般实现了消息的可靠性送达，高并发下的数据集群服务。作者回复: 谢谢留言！总结得不错啊！不过消息队列也不一定是可靠性送达的，在一些极端的情况下也是有可能出现丢包。