分布式day1

一、自增主键

问题描述：大表为什么不能用自增主键，UUID 为什么不可以用于自增逐渐，SnowFlake 雪花算法是什么？

1、自增主键在分布式系统中会产生尾部热点效应，在构建数据库集群中会造成资源的浪费，无法在运行期间进行动态扩展。

尾部热点：按id号范围分片，所有的操作都在一个分片上，造成单表查询压力大。

2、UUID 是无序的，作为主键会涉及大量索引重排。在innoDB 引擎中采用b+树结构，所有的节点数据按照顺序排列，新增结点后只需追加在已经排好的顺序后。

3、分布式环境下唯一的、有序的UUID：SnowFlake算法（时间回拨问题）

二、接口幂等性

幂等性：发一次接口调用与发多次相同的接口消息都能得到与预期相符的结果

构建幂等表：在原有业务基础上，构建一个用于检查接口幂等性的数据表，来保证每个业务请求被后台的方法真正处理一次。

三、乐观锁处理并发冲突问题：既要保证用户体验，也要实现数据可靠

1、传统解决方案（悲观锁），在select 语句上加上for update ，在原有数据上加上行锁

开始事务

select * from acc where id = 1001 for update

update acc set bal = 500 where id =1001

提交

悲观锁并发性差，高并发场景用户体验差

2、乐观锁，通过版本号实现并发控制。

    开始事务

    select * from acc where id =1001

    update acc set bal = 500, version = version +1 where id =1001 and version = 1

    提交

此时若version不对，提交不成功，造成用户体验差。可以使用spring-retry 进行方法重试。

四、mysql 集群模式与应用场景

1、读写分离集群模式，可使用mysql自带的主从同步机制binlog日记同步，保证数据库间的数据同步。主库复制数据的写入，从库负责数据的读，所有节点的数据都是同步的。在实际应用中，直接对主库的操作无法完成读写分离，需要使用分片中间件，把请求按照负载规则发到对应的数据库。

读写分离缺点：结构的负责度提高，数据的一致性问题，硬件成本提高。

2、分库分表，使用分片中间件（MyCat）

分片算法：范围法、hash

互联网主流MySQL集群方案：读写分离以及分片法应用。