主要用于分散压力，所以分布式的服务都是部署在不同的服务器上的，再将服务做集群
根据“分层”的思想进行拆分。
例如，可以将一个项目根据“三层架构” 拆分
然后再分开部署 ：
根据业务进行拆分。
例如，可以根据业务逻辑，将“电商项目”拆分成 “订单项目”、“用户项目”和“秒杀项目” 。显然这三个拆分后的项目，仍然可以作为独立的项目使用。像这种拆分的方法，就成为垂直拆分
主要用于分散能力，主要是将服务的颗粒度尽量细化，且自成一脉，压力这块并不是其关注的点，所以多个微服务是可以部署在同一台服务器上的
微服务可以理解为一种 非常细粒度的垂直拆分 。例如，以上“订单项目”本来就是垂直拆分后的子项目，但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”，如图
现在看图中的“订单项目”，它完全可以作为一个分布式项目的组成元素，但就不适合作为微服务的组成元素了（因为它还能再拆，而微服务应该是不能再拆的“微小”服务，类似于“原子性”）
分布式服务需要提供给别的分布式服务去调用，单独拆出来 未必外部可用
微服务自成一脉，可以系统内部调用，也可以单独提供服务
为什么需要用分布式锁，见下图
变量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 差不多，都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚。
适用于对实时性要求没那么高的业务场景，如：短信通知
这就是python中著名的and-or技巧了！python中没有C语言里面方便的?:算符，但是这个技巧可以发挥相同的作用。如果x<y为真，取and后面的第一项
如果x<y为假，取and后面的第二项
至于中括号是为了防止x=0这种特殊情况，因为and-or技巧此时不起作用——这也是唯一需要注意的特例。例如x=0,y=1：此时显然为真，但是x<y and x or y中因为x为假，所以最后得到的是y——较大的那个。但是加上中括号[x]=[0]是一个真值，最后得到的是[0]。之后在取第0项就行了~
