分布式锁-session-事务相关

1. 分布式锁--zookeeper

1). client调用create()方法创建“/root/lock_”节点，注意节点类型是EPHEMERAL_SEQUENTIAL。
2). client调用getChildren("/root/lock_",false)来获取所有已经创建的子节点，这里并不注册任何Watcher。
3). 客户端获取到所有子节点Path后，如果发现自己在步骤1中创建的节点是所有节点中最小的，那么就认为这个客户端获得了锁。
4). 如果在步骤3中，发现不是最小的，那么找到比自己小的那个节点，然后对其调用exist()方法,并注册事件监听移除事件。
5). 之后一旦这个被关注的节点移除，客户端会收到相应的通知，这个时候客户端需要再次调用getChildren("/root/lock_",false)来确保自己是最小的节点，然后进入步骤3.

2. 分布式session--redis

1). 将session已sessionId作为key，保存缓存集群中.
2). 请求到来时从缓存中加载session，出来后写回.

//tomcat基于redis
	使用功能tomcat-redis-session-manager， 设置non-sticky模式，每次映射到后端的server是不同的，当请求到来时，
从redis中恢复session，处理完成后session再写回redis.

3. 分布式事务-消息队列来避免分布式事务

3.1 消息队列来避免分布式事务

	当支付宝账户扣除1万后，我们只要生成一个凭证（消息）即可，这个凭证（消息）上写着“让余额宝账户增加
1万”，只要这个凭证（消息）能可靠保存，我们最终是可以拿着这个凭证（消息）让余额宝账户增加1万的，即我们能
依靠这个凭证（消息）完成最终一致性。

3.2 两阶段提交协议--多次通信，性能太差

缺点:
	1）两阶段提交涉及多次节点间的网络通信，通信时间太长！
	2）事务时间相对于变长了，锁定的资源的时间也变长了，造成资源等待时间也增加好多！

过程--数据库前需要一个TC(事务协调器)
	1） 我们的应用程序（client）发起一个开始请求到TC；
	2） TC先将<prepare>消息写到本地日志，之后向所有的Si发起<prepare>消息。以支付宝转账到余额宝为例，TC给A的prepare消息是通
		知支付宝数据库相应账目扣款1万，TC给B的prepare消息是通知余额宝数据库相应账目增加1w。为什么在执行任务前需要先写本地日志，
		主要是为了故障后恢复用，本地日志起到现实生活中凭证 的效果，如果没有本地日志（凭证），出问题容易死无对证；
	3） Si收到<prepare>消息后，执行具体本机事务，但不会进行commit，如果成功返回<yes>，不成功返回<no>。同理，返回前都应把要返回的消息写到日志里，当作凭证。
	4） TC收集所有执行器返回的消息，如果所有执行器都返回yes，那么给所有执行器发生送commit消息，执行器收到commit后执行本地事务的commit操作；
		如果有任一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后执行事务abort操作。

注：TC或Si把发送或接收到的消息先写到日志里，主要是为了故障后恢复用。如某一Si从故障中恢复后，先检查本机的日志，如果已收到<commit >，则提交，如果<abort >则回滚。如果是<yes>，则再向TC询问一下，确定下一步。如果什么都没有，则很可能在<prepare>阶段Si就崩溃了，因此需要回滚。

4. 分布式日志

4.1 问题定位-采集日志

统一的日志web端 --> 输入日志关键字,一般opeId --> 点击开始 --> 办理业务 --> 点击结束 --> 后台去各个业务节点日志中按起止时间+oprId过滤
	-->汇总日志返回 --> 保存分析即可

4.2 动态修改日志级别