分布式锁
数据库的唯一索引
建立个表，搞个唯一索引（约束），把要操作的对象（比如id作为唯一约束）写入表。可以保证该记录只被插入一次，释放锁时删除这条记录。
非阻塞锁，如果解锁失败
Redis 的 SETNX 指令
- 上锁: SET resource_name my_random_value NX PX 30000
- 解锁: if get resource_name == my_random_value then del resource_name，不能直接del，因为resource_name可能已过期且被其他线程使用。
Redis的 RedLock 算法
保证在发生单点故障时仍然可用。
- 尝试从 N 个相互独立 Redis 实例获取一大半锁
- 耗时小于锁的过期时间就为成功
- 失败就释放已上锁的
Zookeeper
分布式事务
涉及到操作多个数据库
消息队列
下单后push消息到消息队列，库存这边需要pull消息
2PC
两阶段提交协议，保证了事务的原子性。
下单，减存，各自执行但都没提交，等第三方协调者确认所有参与者都执行成功后下达提交指令。
协调者故障导致参与者阻塞，网络导致消息不通
CAP
分布式系统最多满足两个,AC二选一
一致性 Consistency
数据一致更新，所有副本变动都是同步的
可用性 Availability
好的响应性能
分区容忍性 Partition
节点分成几个区后，某些挂了，其他仍要继续提供服务。可靠性
BASE
BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
基本可用
Basically Available
指分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。
例如，电商在做促销时，为了保证购物系统的稳定性，部分消费者可能会被引导到一个降级的页面。
软状态
Soft State
指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在时延。
最终一致性
Eventually Consistent
数据副本，在经过一段时间的同步后，最终能达到一致的状态。
ACID 要求强一致性，通常运用在传统的数据库系统上。
BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。
在实际的分布式场景中，不同业务单元和组件对一致性的要求是不同的，因此 ACID 和 BASE 往往会结合在一起使用。
Paxos
让参与分布式处理的每个参与者逐步达成一致意见
- 提议者
- 接受者
多对多关系，两个阶段：
- 准备：提议者群发序号，接受者群收并记录最大值max
- 接受：提议者群发[序号，内容]，对于某个接受者，若收到的序号 < max，否定，否则接收。
提议者从众，若在准备阶段被反馈有同人提议被接受，从之，若多人，从最大。
接受者从认序号，第二阶段才正式接受
如何浅显易懂地解说 Paxos 的算法
- 可终止性： 从众
- 正确性：接受者只接收一个意见
Raft
通过集群方式，为客户提供强一致、高可靠的数据服务
- 1个Leader n个Follower
- Leader接受客户端请求，并命令Follower一起来做
- 一半的以上回复OK才commint日志
- Leader一直发送心跳信息给Follower
- Follower等随机秒后收不到心跳就变为Candidate进行竞选，投自己，再拉票，一个一票
- 因为是随机秒，所以不会同时竞选，拉票信息随机延迟
- 票数过半为胜者，成Leader,其他为Follower
- Leader负责一致性检查，Follower要保证与其一致，否则将来竞选时可能被更新结点拒绝。
实践
负载均衡的算法与实现
- 加权最小连接
- DNS
- MAC
- IP
- HTTP重定向
分布式session
- 把client固定到server,一旦故障session全丢
- Session 复制，一旦变化就广播，优化方案（Terracotta只广播改动的部分）
- Memcached或数据库
高并发下的性能优化
- 调整项目结构，增加服务器资源，集群或分布式，负载均衡
- 数据库优化
- 代码优化（使用多线程+算法优化）
- 合理使用缓存
- html静态化，图片存于服务器
接口如何处理重复请求
- 前端 disable
- 后端 redis分布式锁
接口限流
计数器法，1分钟100，临界时间点
滑动窗口，将时间细分为很多格，每过n秒向右移动n格
漏桶算法 令牌桶算法
分布式缓存
https://github.com/crossoverJie/JCSprout/blob/master/MD/Cache-design.md