分布式和微服务的区别
从设计理念上来看
- 分布式用于分散压力
- 微服务用于分散能力
从部署角度上来看
分布式
主要用于分散压力，所以分布式的服务都是部署在不同的服务器上的，再将服务做集群
分布式水平拆分
根据“分层”的思想进行拆分。
例如，可以将一个项目根据“三层架构”拆分
- 表示层（jsp+servlet）
- 业务逻辑层（service）
- 数据访问层（dao）
然后再分开部署：
- 把表示层部署在服务器A上
- 把service和dao层部署在服务器B上（当然，业务逻辑层和数据访问层也可以分开部署在不同服务器上）
- 然后服务器A和服务器B之间通过dubbo等RPC进行进行整合，如图所示。
分布式垂直拆分
根据业务进行拆分。
例如，可以根据业务逻辑，将“电商项目”拆分成“订单项目”、“用户项目”和“秒杀项目”。显然这三个拆分后的项目，仍然可以作为独立的项目使用。像这种拆分的方法，就成为垂直拆分
微服务
主要用于分散能力，主要是将服务的颗粒度尽量细化，且自成一脉，压力这块并不是其关注的点，所以多个微服务是可以部署在同一台服务器上的
微服务可以理解为一种非常细粒度的垂直拆分。例如，以上“订单项目”本来就是垂直拆分后的子项目，但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”，如图
现在看图中的“订单项目”，它完全可以作为一个分布式项目的组成元素，但就不适合作为微服务的组成元素了（因为它还能再拆，而微服务应该是不能再拆的“微小”服务，类似于“原子性”）
从服务完整性来看
分布式服务需要提供给别的分布式服务去调用，单独拆出来未必外部可用
微服务自成一脉，可以系统内部调用，也可以单独提供服务
分布式锁
WHY
为什么需要用分布式锁，见下图
变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的。
分布式锁应该具备哪些条件：
1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败
HOW
利用redis实现分布式锁
WHY
Redis性能高
命令简单，实现方便
HOW
获取锁
使用setnx加锁，key为锁名，value随意不重复就行（一般用uuid）
给锁添加expire时间，超过该时间redis过期（即自动释放锁）
设置获取锁的超时时间，若超过时间，则放弃获取锁
释放锁
通过锁名获取锁值
比较锁值和当前uuid是否一致，一致则释放锁（通过delete命令删除redis键值对）
EXAMPLE
#连接redis
import time
import uuid
from threading import Thread
import redis
redis_client = redis.Redis(host="localhost",
port=6379,
# password=123,
db=10)
#获取一个锁
# lock_name：锁定名称
# acquire_time: 客户端等待获取锁的时间
# time_out: 锁的超时时间
def acquire_lock(lock_name, acquire_time=10, time_out=10):
"""获取一个分布式锁"""
identifier = str(uuid.uuid4())
end = time.time() + acquire_time
lock = "string:lock:" + lock_name
while time.time() < end:
if redis_client.setnx(lock, identifier):
# 给锁设置超时时间, 防止进程崩溃导致其他进程无法获取锁
redis_client.expire(lock, time_out)
return identifier
elif not redis_client.ttl(lock):
redis_client.expire(lock, time_out)
time.sleep(0.001)
return False
#释放一个锁
def release_lock(lock_name, identifier):
"""通用的锁释放函数"""
lock = "string:lock:" + lock_name
pip = redis_client.pipeline(True)
while True:
try:
pip.watch(lock)
lock_value = redis_client.get(lock)
if not lock_value:
return True
if lock_value.decode() == identifier:
pip.multi()
pip.delete(lock)
pip.execute()
return True
pip.unwatch()
break
except redis.excetions.WacthcError:
pass
return False
分布式事务
2PC方案
2PC：two phase commit protocol，二阶段提交协议，是一种强一致性设计。
同步阻塞（导致长久的资源锁定），只有第一阶段全部正常完成（返回失败，回字返回超时都会返回“准备失败”），才会进入第二阶段
流程
- 准备。除了commit之外的所有命令都已完成
- 协调者接收所有准备的响应
- 所有资源响应后，进入第二阶段，提交/回滚阶段（只要准备阶段有一个是准备失败，那么所有节点的事务全部回滚）
- 若第二阶段失败，不管是回滚还是提交，就不断重试，直到所有都回滚成功或者提交成功
协调者设计
因为协调者可能会在任意一个时间点（发送准备命令之前，发送准备命令之后，发送回滚事务命令之前，发送回滚事务命令之后，发送提交事务命令之前，发送提交事务命令之后）故障，导致资源阻塞。
3PC方案
流程
- 准备阶段，只是询问参与者是否有条件接收事务，并没有像2PC那样，上来就直接执行了除commit之外的所有工作，就不会一上来就直接锁定资源
- 预提交阶段，就像2PC的准备阶段，除了事务的提交，该做的都做了
- 提交阶段，和2PC的提交阶段一样
TCC解决方案
T：try，指的是预留，即资源的预留和锁定，注意是预留
C：confirm，指的是确认操作，这一步其实就是真正的执行了
C：cancel，指的是撤销操作，可以理解为把预留阶段的动作撤销了
从思想上看和 2PC 差不多，都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚。
劣势
- 对业务入侵较大，与业务紧耦合（需要根据具体业务，对每一个动作都要写一份tcc）
- 提交和撤销可能需要重试，所以要保证幂等性
最终消息一致性方案
WHERE
适用于对实时性要求没那么高的业务场景，如：短信通知
HOW
- A服务器数据表操作 + 消息表操作
- A的数据和消息表内容发生消息到MQ（如果失败，尝试重新发送，属于消息队列的机制）
- B服务器接收MQ消息，执行自己的逻辑。如果B的本地事务成功，不回传消息；如果B的本地事务失败，发消息给MQ，A接收MQ消息，执行回滚操作。（如果失败，尝试重新发送，属于消息队列的机制）
- A服务器和B服务器定时扫描本地消息表，把没处理完的消息或者失败的消息再发送一遍。（防止网络异常导致回滚失败）
