从站点到平台——探讨服务端高并发分布式架构演进

主要用于分散压力，所以分布式的服务都是部署在不同的服务器上的，再将服务做集群

根据“分层”的思想进行拆分。
例如，可以将一个项目根据“三层架构” 拆分

然后再分开部署 ：

根据业务进行拆分。
例如，可以根据业务逻辑，将“电商项目”拆分成 “订单项目”、“用户项目”和“秒杀项目” 。显然这三个拆分后的项目，仍然可以作为独立的项目使用。像这种拆分的方法，就成为垂直拆分

主要用于分散能力，主要是将服务的颗粒度尽量细化，且自成一脉，压力这块并不是其关注的点，所以多个微服务是可以部署在同一台服务器上的

微服务可以理解为一种 非常细粒度的垂直拆分 。例如，以上“订单项目”本来就是垂直拆分后的子项目，但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”，如图

现在看图中的“订单项目”，它完全可以作为一个分布式项目的组成元素，但就不适合作为微服务的组成元素了（因为它还能再拆，而微服务应该是不能再拆的“微小”服务，类似于“原子性”）

分布式服务需要提供给别的分布式服务去调用，单独拆出来 未必外部可用
微服务自成一脉，可以系统内部调用，也可以单独提供服务

为什么需要用分布式锁，见下图

变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量 *** 作，显然结果是不对的！即使不是同时发过来，三个请求分别 *** 作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的。

分布式锁应该具备哪些条件：

1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败

Redis性能高
命令简单，实现方便

使用setnx加锁，key为锁名，value随意不重复就行（一般用uuid）
给锁添加expire时间，超过该时间redis过期（即自动释放锁）
设置获取锁的超时时间，若超过时间，则放弃获取锁

通过锁名获取锁值
比较锁值和当前uuid是否一致，一致则释放锁（通过delete命令删除redis键值对）

2PC：two phase commit protocol，二阶段提交协议，是一种强一致性设计。
同步阻塞（导致长久的资源锁定） ，只有第一阶段全部正常完成（返回失败，回字返回超时都会返回 “准备失败” ），才会进入第二阶段

因为协调者可能会在任意一个时间点（发送准备命令之前，发送准备命令之后，发送回滚事务命令之前，发送回滚事务命令之后，发送提交事务命令之前，发送提交事务命令之后）故障，导致资源阻塞。

T：try，指的是预留，即资源的预留和锁定，注意是预留
C：confirm，指的是确认 *** 作，这一步其实就是真正的执行了
C：cancel，指的是撤销 *** 作，可以理解为把预留阶段的动作撤销了

从思想上看和 2PC 差不多，都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚。

适用于对实时性要求没那么高的业务场景，如：短信通知

我们公司使用的就是微服务加分库分表，一般来说如果应用系统出现性能瓶颈或者业务代码耦合过重，可考虑使用微服务架构，而后端的数据库通常使用读写分离，双主互备或者是分库分表来实现性能的提升和数据服务的高可用。

在数据分布在不同的数据库服务器的带来良好性能的同时，新的问题也随之而来，比如说数据一致性的保证，性能监控，数据存取复杂等，而较为突出的就是数据跨库问题！数据分布在不同的节点上，导致原来的连接查询需要跨库，字段的主键难以保证唯一，跨库的事务处理复杂，下面逐一解决:

1，连接查询(join)问题:因为库表分布在不同的机器上，连接查询失效。

解决办法:

①，代码解决:根据某个字段进行hash的方式进行分库分表，保证落在一个库中的类似表中(比如aa_00t_user_0000和aa_00t_member_0000)，然后基于这样的规则在代码中进行连接查询语句书写！

②，同步:将常用的，需要的字段同步到一个库中进行联合查询！

③，冗余:在一个库中冗余更多的连接查询需要的字段，保证全部数据都能查询到！

2，唯一主键:如果使用传统的自增等方式，多库中的主键id势必重复，所以需要对唯一性加以控制！

解决方法:UUID(根据机器ID，时间等)，redis(单线程保证不重复)，snowflake算法！

3，分布式事务:

1，TCC:try控制业务代码流程，Confirm确认事务的正确性，cancel取消失败的事务！

2，基于消息系统的一致性方案:单节点事务完成后，通过发送消息保证事务提交，如果失败可通过重试，任务补偿等方式保证数据一致性！

总的来说，分布式系统有着很多以往不存在的问题，还需要具体问题具体分析，可一起交流，更多的技术分享，敬请关注。。。

---