kafka和nsq相关整理

kafka

1. 一个topic多个partition，一个partition一主多从，leader承担所有的读写，然后同步到follower。
2. 老版本producer/consumer需要直接和zk交互，新版本直接和broker交互，因为zk写性能不好。
3. producer内部维护内存队列，异步一定间隔或数量发送到broker，失败的话，默认重试3次；同步发送，需要实时调用flush。
4. 每个partition分布在不同server，一个partition只能被同组的一个consumer消费，一个consumer可以消费多个partition，所以一个topic在多个partition的情况下是无法保证有序的，为了简单和有序，consumer的数量不能大于partition的数量。
5. 某个消息只有当所有follower都保存成功，这条消息才能被消费。
6. 一旦出现leader出现故障，follower选举新leader时，可能遇到所有follower都落后于leader的情况，这时候可以选择最新的follower成为leader，但是可能碰到partition过多的问题。
7. kafka使用pull模式，好处是消费速度可控，消费进度也可控。
8. kafka消息投递机制推荐至少一次投递，如果未接收成功重新投递直到成功，对于服务端而言，重复消费要比丢数据好处理。
9. kafka写入高性能（1. 单个文件顺序写，多个文件或者磁盘会出现随机写；2. 先写buff再flush到磁盘，减小io次数）
10. kafka读取指定offset（1. 文件大小指定，可以通过offset和文件大小计算出数据在哪个文件，2. 通过chunk size以及基于有序消息的二分查找，可以快速定位到指定offset）
11. producer/consumer信息存储zookeeper，kafka的consumer本地记录offset，一定时间间隔注册zk。
12. 据说机械硬盘顺序写比内存随机读要快。
13. partition删数据：partition其实是个文件夹，segment是文件夹里面的小文件，过期或者磁盘不足可以删除比较老的segment。
14. 消息路由默认实现，消息轮流选择partition，好处：负载均衡，坏处：同一个用户的消息可能放到不同的partition。
15. 自治rebalance机制（旧）：每次group的consumer出现变更，所有consumer都退出group然后，重新加入group触发分配partition。自治rebalance，通过zk保存状态，自身计算自己应该消费partition，坏处：这种情况依赖了zk的数据一致性，可能出现脑裂，不可控；每次变更都触发计算；好处：简单。
16. 集中rebalance机制（新）：zk为每个group选定一个leader，由leader计算分配方案，存放在syncGroup，然后每个consumer主动syncGroup拉去方案并且执行监听。
17. ISR机制：partition的follower异步同步，但是需要所有follower成功commited，消息才能被消费。这里的异步指的是leader已经接收到消息并且写入磁盘，但是还没commited，目前可以配置时间间隔，如果落后时间大于指定配置，把备份从ISR剔除，可以保证吞吐率和一致性。如果leader挂了，从ISR中选择活的节点选为leader，原本故障节点恢复时，首先先剔除未commit的消息，然后同步当前leader的节点数据，直到一致才能重新加入ISR。如果ISR都不可用，两种策略：1. 等待以前ISR中的任何一个备份恢复（慢，但是数据不丢失），2. 等待任何一个备份恢复无论以前是否在ISR（默认策略，快，数据丢失，比如故障节点）

nsq

1. 所有消息存在nsqd里面，存内存不落盘，消息可能丢失
2. 至少一次成功发送，大致保证这个特性，因为内存消息会丢
3. topic逻辑概念，多个channel，消息发至topic，会复制到每个channel
4. 每一个channel有完整的消息，多个channel类比于广播
5. 无序：1. 特色功能，处理消息失败requeue，延迟消费defer。2. 一旦内存无法存下，会写磁盘，但是这个是无序的。
6. 不可回溯，channel成功消费后会删除消息。
7. push：相对于pull更实时，流量监控。

kafka与nsq的对比：https://www.codercto.com/a/30746.html