我们做一个网站或者 app, 最开始我们设计系统因为用户量很小, 不需要设计成分布式系统, 单机足以能满足用户需求, 但当我们用户量越来越大, 计算量越来越大, 业务越来越复杂, 单机已经不能满足业务需要, 这时我们需要分布式系统来解决业务计算增长带来的问题
分布式系统通过副本大幅提高系统可用性以及系统吞吐量因为副本从理论上本身增加一倍的处理能力, 能够处理更多请求, 通过花费一倍空间的方式
分布式本身也带来一些问题, 很关键一个问题数据一致性, 比如主从节点, 从节点与主节点数据不一致, 那么当我们从从节点取获取数据时就与程序从主节点去获取数据不一致, 对于支付这种关键性业务是可接受的, 所以当我们是否选择分布式系统时需要根据实际情况去选择, 根据实际业务去考虑, 不能没有依据去选择架构
分布式系统分布式计算优势明显, 能够提升 qps 能够处理更多用户服务高可用 (一台有问题其他机器提供服务, 对用户完全无感知, 分布式系统一个显著特点, 如果一台机器有问题用户感知不到, 那么用户就是在和分布式系统打交道), 但是也要面临一些列的问题, 比如一致性问题, 一致性包含数据一致性以及时间一致性很大程度上分布式系统都在解决一致性问题, 处理好一致性问题, 才能更好地对外提供服务
数据复制一致性, 分布式系统本质上是由一些列单个计算节点组成, 通过分布式操作系统, 分布式中间件来将节点组合在一起形成分布式系统对于分布式存储来说, 主与从节点数据一致性是存储向外提供无差错无偏差数据基石
分布式一致性 CAP 理论即 Consistency 一致性, 在事务开始或结束时, 数据库应该在一直状态, Isolation 隔离性, 事务假定只有它自己在操作数据库, 彼此不知晓, Durablity 一旦事务完成就不能返回分布式存储或者说分布式数据库同时达到三种状态很难, 会取舍权衡同时满足两个状态
实际分布式数据库 redis 分布式消息队列 kafka, 主从数据一致性是利用主从连接断开时间 redis 是主从 offset 是否一致 kafka 是主从游标是否一致, 通过结合主从连接时间以及游标偏移量等来保证主从数据一致和一致性理论有一定差异, 理论上一致性算法 paxos, 并且 paxos 作者 lamport 说了所有一致性算法都是 paxos 变种
实际数据复制没有应用 paxos 算法是因为一是工程实践上的复杂程度大, 会有 bug 隐患, 以及性能上的考虑, 因为投票算法依赖网络状况以及集群规模, 网络状况越差, 集群规模越大会导致整个算法性能越差, 会达不到实际工程需要
主从选举一致性更多还是基于 paxos 算法的 zookeeper, 在 java 分布式领域主从选取都是用 zookeeper 进行实现, hadoophbasekafka 都是采用 zookeeper 实现主从选举
公司内节点 redis 集群, redis 本身是 c 语言开发, 判活采用的是自研逻辑, 判活服务为有一个节点判断 redis 节点存活即为存活, 判活服务所有节点投票 redis 节点非存活状态则可以创建新的 redis 节点替代原有节点, 有一个节点未判断不存活则为存活状态如改造 redis 对接 zookeeper 成本高, 而且方案复杂, 容易有 bug
来源: http://www.tuicool.com/articles/yMZb22Z