Java项目架构听课总结第二天，虽然我没有经验，但是我听了以后收获很大，概括总结。

1 习惯、经验：
开发的时候常用的接口的细节要记住

做架构解决需求的时候一团乱麻 ，需要拔高，站在更高的角度去看，需求会更加清晰

需求包括流程图和规则，规则是可配置的流程图是固定的，一般吧规则放在缓存中因为，多读少写的特点，和高并发的压力导致更适合选择放在缓存而不是数据库中
2 网约车项目的特殊经验
对于司机抢单逻辑：发出请求 到 判断是否被抢，若被抢则抢单失败，若不被抢，先上锁然后把司机id放上去，上锁是为了不让其他司机同时抢，一般不使用数据库里的锁，因为当服务器过多时高并发的情况下可能出现在这个服务器里这个订单能被抢，同时别的服务器里这个订单也被抢，应该用第三方锁，让所有的服务器都通过第三方判断这个订单是否已经有人在抢了
3 什么是第三方

MYSQL（中小型项目，硬存做io，要是想省钱可以用内存做io）分布式锁 插入一条记录做加锁，利用主键的唯一性，就用表当锁
MYSQL qps 每秒查询率 性能在于花不花钱，跟配置有关 不能抛开配置说性能

REDIS （中大型项目）性能比MYSQL好
REDIS 单节点解决方案 setnx key value 释放锁 del key 有人拿到了锁，别人在用锁就不成功

一个请求 要了个kv值 但是请求挂了，所以就变成了一个死锁，怎么解决，应该设置一个过期时间（原子操作），

如果key过期但是程序没走完 如果一个程序没走完 新的程序出现（放条狗 给锁续期上一个程序跑完了把狗也放了，如果狗死了主人跑不了，key也过期了）弄了新的key 上一个程序的del就把这个新的key干掉了（解决方案：判断是否是我自己加的锁在释放）

REDIS集群方案
一主二从三哨兵为了避免Redis单点故障
主挂了从上但是从没有key 为了解决这个问题一个服务要加多个锁，别人在加锁就会失败，只要无法过半，只要是奇数台就ok
ZOOKEEPER
ETCD
LCN
TCC

有时就会出现这种并发的bug，一定要用并发工具测试Jmete LoadRouner，低并发用前者，高并发用后者，遇到问题仔细看日志的报错，基本上日志Log就告诉你报错了

请求 到 api 到service