Raft 算法是一个共识的算法,在集群的分布式状态中,保证每个节点都处于一致的状态。
Raft 算法主要可以分为两个阶段:
- 领导者选举阶段
- 日志复制(数据同步)阶段
Zab(Zookeeper 采用的一致性协议)、或 Paxos 算法来保证 kafka 副本的数据一致性,而是采用另一套 ISR 副本管理机制来保证数据一致性呢?
redis raft协议数据一致性
客户端每发送一个更新请求,ZooKeeper 都会生成一个全局唯一的递增编号,这个编号反映了所有事务操作的先后顺序,这个唯一编号就是事务 ID(ZXID),只有更新请求才算是事务请求。
为保证按照事务的 ZXID 先后顺序来处理,Leader服务器会分别为每个 Follower 服务器创建一个队列,并将事务的先后顺序放入队列中,并按照 FIFO 的策略进行消息发送。收到需要处理的事务后,Follower 服务器会首先以事务日志的形式写入服务器的磁盘中,写入成功后会向 Leader 服务器发送 ACK 响应。当 Leader 服务器收到超过一半的 Follower 服务器的 ACK 响应后,会向所有 Follower 服务器广播 Commit 消息,收到 Commit 消息的 Follower 服务器也会完成对事务的提交。
如果接收到事务请求的是 Follower 服务器,它会将请求转发给 Leader 服务器处理。
Kafka 是一个分布式流平台。是一种高吞吐量的分布式发布订阅消息系统。
消息中间件一般支持两种模式的队列:
一是消息队列模式
二是发布订阅 (Pub-Sub) 模式
Kafka 是发布订阅模式的轻量级消息系统、流平台。
这个系统需要满足如下三个特性:
gRPC 是一个远程过程调用框架,默认使用 protobuf3 进行数据的高效序列化与 service 定义,使用 HTTP/2 进行数据传输。 这里讨论的是 gRPC over HTTP/2 协议。
目前 gRPC 主要被用在微服务通信中,但是因为其优越的性能,它也很契合游戏、loT 等需要高性能低延迟的场景。
其实从协议先进程度上讲,gRPC 基本全面超越 REST:
Redis 中为了实现高可用(High Availability,简称 HA ),采用了如下两个方式:
主从模式(Redis 2.8 版本之前的模式)、哨兵 sentinel 模式(Redis 2.8 及之后的模式)、redis cluster模式(Redis 3.0版本之后)
Data structures are nothing different. They are like the bookshelves of your application where you can organize your data. Different data structures will give you different facility and benefits. To properly use the power and accessibility of the data structures you need to know the trade-offs of using one.
不同的数据结构有不同的适用场景和优缺点,你需要仔细权衡自己的需求之后妥善适用它们
布隆过滤器就是践行这句话的代表