Kafka
Kafka一个partition只能被一个消费者组中的一个consumer消费，即consumer的数量不能多于partition，但一个consumer可以消费多个partition
Kafka手动提交带来的问题
- 消息丢失（offset提交之后，OOM，那超出内存的数据将永远不会被消费）
- 重复消费（拿到一批数据后消费一部分后，宕机了，之后又会从先前的offset处开始拉消息消费）
auto.offset.reset earliest,latest(默认) none
当各分区下有已提交的offset时，earliest/latest都会从提交的offset开始消费
当各分区下无提交的offset时，earliest从头开始消费，latest消费新产生的该分区下的数据
即：提交过offset，latest和earliest没有区别，但是在没有提交offset情况下，用latest直接会导致无法读取就数据
none：当各分区都存在已提交的offset时，从offset后开始消费，只要有一个分区不存在已提交的offset，则抛出异常
Kafka的Replication不提供对外访问
Elastic-job（基于Zookeeper、Quartz）
分布式定时任务，解决 Quartz
- 任务多节点部署而带来的重复执行问题
无法水平拓展（节点数量的增加不能给我们的每次执行效率带来提升）
基于Zookeeper，实现的全局作业注册调度控制中心。将任务拆分为n个子任务项后，各个服务器分别执行个字分配到的子任务项
Zookeeper实现分布式作业调度的原理 https://blog.csdn.net/HappyHeng/article/details/83478539
而相比于xxl-job，是基于DB来实现的，任务数量比较大，对DB会产生压力，各节点会上报任务，存到数据库中，执行时从数据库中取出触发器来执行，如果触发器的名称和执行时间相同，则只有一个节点去执行此任务
ES为什么这么快？
- 多节点集群提高系统兵法
- 分片副本提高搜索速度
- 乐观锁并发控制
- translog事务日志，可保证文档驾到内存缓冲区就可以被搜索
- 其segment的不变性，分段存储，FST结构高效的数据压缩率和查询效率等
ES增删改原理
- 客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）
- coordinating node对document进行路由，将请求转发给对应的node（有primary shard）
- 实际的node上的primary shard处理请求，然后将数据同步到replica node
- coordinating node，如果发现primary node和所有replica node都搞定之后，就返回相应结果给客户端
ES读取原理
- 客户端发送请求到任意一个node，成为coordinate node
- coordinate node对document进行路由，将请求转发到对应的node，采用随机轮询算法，在primary shard以及其所有的replica中随机选择一个，让读请求负载均衡
- 接收请求的node返回document给coordinate node
- coordinate node再返回document给客户端
ES搜索原理
- 搜索请求发送到某一个coordinate node，构建一个priority queue，长度以paging操作from和size为准
- coordinate node将请求打到所有的primary shard上去执行 因为每个shard都可能包含搜索请求的结果(如果有replica shard也会将请求打到replica shard)
- 每个shard本地搜索，并构建一个本地的priority queue，各个shard将自己的priority queue返回给coordinate node，coordinate node进行merge并构建一个全局的priority queue
coordinate node的priority queue中是一堆doc id，这时coordinate node就会发送mget api去各个shard上批量一次性获取数据返回
Aerospike
一个K-V的Nosql，存储在SSD上，且可以保证大规模的数据下，也能低延迟，高吞吐，相比于redis，在大数据量时，可扩展性就差了，而且基于内存还很贵
基本概念：NameSpace(库) > Set(表) > Records(行) > Key(全局唯一类似主键) , Bins(列),Metadata(元数据)
但他只保证AP会存在数据不一致的情况