qq_32680371的博客

Raft算法是一切以领导者为主，在分布式系统中，就一系列值达成共识与日志的一致。是一种强领导者模型，领导者的性能决定了整个集群的性能。它是现今最常用的一种分布式共识算法。领导者选举Raft算法使用如下的三个角色，描述每个节点的状态。1、领导者(Leader)：集群中的霸道总裁，其主要职能是处理写请求、同步日志给其余节点与发送心跳信息。领导者通过心跳信息，告诉其他节点我还活着，别进行领导者选举。在正常情况下，选举出来的领导者会一直是领导者。2、跟随者(Follower)：默默的接受领导者节点的日志复制

什么是分布式事务分布式事务就是在分布式系统中运行的事务，它是由多个本地事务组成的。也需要满足事务的ACID特性。关于ACID见我的博文《事务的ACID特性与隔离性分析》二阶段提交二阶段提交协议(The two-phase commit protocol, 2PC)，是用于保证分布式事务的原子性与一致性，其分为投票(vote)与提交(commit)2个阶段。为了实现二阶段提交，需要引入协调者(coordinator，即事务的管理器)，来保证事务的原子性与一致性。1、投票(vote)为第一阶段，协调者(

CAP定理CAP定理指的是在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。注意这里是互相连接并且共享数据的集群并且涉及到数据的读写，比如MySQL集群。一致性（Consistency）指对某个指定的客户端来说，读操作保证能够返回最新的写操作结果；可用性（Availability）指非故障的节点在合理的时间内返回

当数据规模达到一定量级的时候会影响到数据库的性能，那么这个时候我们一般会沿着AKF的Z轴使用分库分表的策略，以降低单表的数据量，从而提高数据库的性能。但是分库分表后，我们怎么保证ID的全局唯一性呢？这个时候ID生成器就登场了。ID应该遵循的原则1、ID应该是按时间有序的，因为在某些场景上可能会用到，比如获取商品的评论，一般需要按照评论的倒叙显示，如果评论ID是无序的那边就需要添加额外的字段排序。另外ID如果是有序，可以提升数据库的性能，因为有序的ID，对于关系型数据库来说可以有效的实现插入数据的顺序写磁

如果每次查询数据库都重新创建一个数据库连接，而创建一个新的数据库连接需要走TCP的三次握手与数据库权限认证，这个耗时可能比查询数据库还要耗时，这样就会严重影响服务的性能。为此我们一般引入数据库连接池，事先创建好数据库的连接，每次需要查询数据库的时候从池子里面获取一个空闲的连接。数据库连接池注意事项1、连接池应该有是有上下界的，当如果有比较多的空闲连接且总的连接数大于连接池连接数的下界，那么可以关闭部分空闲连接，空闲连接数的阈值可以根据场景配置；2、当从连接池里面获取连接时，如果有空闲连接则返回空闲连接

限流指的是限制系统的并发访问策略，保证系统能够接受部分用户的请求，而对于超过流量控制的请求，系统会拒绝请求。限流是为了保护系统不会被过载的流量打垮，其通常做在服务入口层如网关，它可以对整个系统，某个服务，某个接口，某个IP或者某个用户做限制。常用的限流算法有固定窗口，滑动窗口，漏桶算法与令牌桶算法。固定窗口固定窗口指的是在固定的时间窗口内限制请求的数量，超过数量的请求直接拒绝。比如限制1分钟内只能接收1W笔请求，超过1W笔的请求直接拒绝请求，等到下一个一分钟重新开始计数。从固定窗口的算法中可以看出，在

假设我们有如下倚赖关系的3个服务，其中A与B是系统的核心服务，C是非核心服务。如果系统某天需要做活动，预估流量可能是平时的3倍，那么我们可能会扩容服务A与B，由于C不是非核心服务，而选择不扩容服务。那么当活动开始时，请求蜂拥而至，服务C达到了系统的瓶颈，从而出现了大量的慢查询，继而导致服务B的大量请求一直在等待C的返回，久而久之服务B的大量资源耗在等待服务C的调用，最终导致服务B出现问题，紧接着服务A也出现了问题。导致了系统的雪崩。一个非核心服务C的慢请求最终演变成了怎个系统的雪崩。所以在分布式环境下

在我的《高并发系统设计目标之可扩展性》博文中提到，随着业务的发展，我们会沿着AKF的Y轴进行微服务化的改造。本文就介绍一下微服务化改造的基本原则微服务化改造原则1、单个服务内部应该是高内聚低耦合的，也就是单一服务内部应该只做自己相关的事情，不是自己职责的功能交由其他服务完成，服务之间应该有明显的边界；2、微服务化改造应该是边改造边支持业务的发展的，不能为了改造而停止业务的迭代。因为要是停止了业务的迭代，那么等你改造完，可能已经被竞品超越了，从而丧失了市场的机会，最终可能是竹篮打水一场空；3、微服务提

在我的《高并发系统设计目标之可扩展性》博文中提到，随着业务的发展，我们会沿着AKF的Y轴进行微服务化的改造。但是沿着Y轴的重构过程中往往涉及到分库分表。那么这时就需要进行数据库的迁移了。那么迁移有什么原则呢？数据迁移原则1、迁移的过程应该是在线的，线上的服务应该能够正常的提供服务；2、迁移完成后，数据应该是完整的，也就是迁移后新库与旧库的数据应该要保持一致；3、迁移过程中如果出现问题，应该是可以回滚。数据迁移之双写方案其流程如下图：1、设置新库同步旧库（快照+binlog），如果新库的库表有

可扩展性我们的系统一般分为平时流量与高峰流量，为了节约成本一般都是预留1到2倍的容量，以应对突发的流量。但是如果突然来了一个大事件，一下来了很多请求，那么此时我们的系统可能承受不了那么多的流量。如果我们的系统的可扩展性非常好，那么我们可以快速的扩展我们的系统，以应对峰值流量。为此我们的系统需要具有良好的可扩展性。如何设计可扩展性的系统那么我们有什么依据来设置我们的系统，以实现良好的可扩展性呢？我们可以基于AKF立方体来拆分我们的系统，以实现高可扩展性。AKF 立方体也叫做scala cube，旨在提

高可用（High Availability,HA）可用性指的是软件系统在投入使用时可正常提供服务的程度，或能实现其指定系统功能的概率，是衡量系统可以无故障的运行的能力。同样是一个每秒可以接受1万次请求的购物系统中，一个隔三岔五的就出现故障，而另外一个可以长时间工作，显然可以长时间工作的系统的体验更好。通常来讲对于一个高并发大流量的系统，系统的可用性通常比系统性能低下的影响更大，一个日活百万的系统，1分钟的故障影响的客户可能有成百上千，想想是多么的可拍。而随着系统的日活的增加，对于可用性的要求就越高。那么可

在高并发分布式系统设计中，我们经常提及三大目标，那么什么是三大目标呢？他们就是高性能、高可用、可扩展性。那么他们有什么衡量标准呢？高性能性能反应了系统的使用体验，性能越高系统的体验越好，比如在一个每秒可以接受1万次请求的购物系统中，一个浏览商品详情页面的响应时间是1秒，而另一个是200ms，显然200ms的系统体验更好。那么性能优化有什么指导原则呢？1、性能优化一定要以问题为导向，不能麻木的优化。麻木的提早优化可能使系统过度设计，进而导致系统过于复杂，进而增加了开发与维护成本，而且还可能影响到将来的

在一致性详解的博文的开篇词中提到，在高并发读写数据的场景中，我们一般会对数据进行hash分片，从而分布到不同的服务器中，那么本文就谈谈常用的hash。数据分片原则数据均匀发布数据均匀分布主要指的是数据需要尽可能均匀的发布在不同的节点上，不能其中一个或几个节点占有大部分数据，这样就失去了数据分片的...

在后台开发中，当我们需要支持大规模的并发读写，同时具备横向扩展能力。这这时我们一般会对数据进行hash分区，从而分布到不同的服务器中，以解决写的瓶颈。同时每个写服务器会通过主从同步分布到多台服务器上面，从而实现读写分离，提高读的并发性能。那么问题来了，一次性写多条数据，怎么保证多台服务器的一致性呢？如果数据同步存在延迟，怎么保证写后一定能读到呢？本文我们就探讨一下一致性的问题。一致性的分类1、我们通常把一致性分为最终一致性与强一致性，那么什么是最终一致性，什么是强一致性呢？最终一致性（Eventua

缓存更新方式很多研发同学是这么用缓存的：在查询数据的时候，先去缓存中查询，如果命中缓存那就直接返回数据。如果没有命中，那就去数据库中查询，得到查询结果之后把数据写入缓存，然后返回。在更新数据的时候，先去更新数据库中的表，如果更新成功，再去更新缓存中的数据。流程如下图这样使用缓存的方式有没有问题？绝大多数情况下都没问题。但是，在并发的情况下，有一定的概率会出现“脏数据”问题，缓存中的数据可能会被错误地更新成了旧数据。比如1，对同一条记录，同时产生了一个读请求和一个写请求，这两个请求被分配到两个不同的线程