分布式一些问题处理方案

分布式ID生成方案

UUID     UUID是通用唯一标识码的缩写，目的是让分布式系统中的所有元素都有唯一的辨识信息，而不需要通过中央控制器来指定唯一标识。

              优点：1：降低全局节点的压力，使得主键生成速度更快

                         2：生成的主键全局唯一

                         3：跨服务器合并数据方便

              缺点：1：UUID占用16个字符，空间占用较多

                         2：不是递增有序的数字，数据写入IO随机性很大，且索引效率下降

数据库主键自增  MySQL设置主键且主键自动增长    

               优点：1：INT，BIGINT类型占用空间较小

                          2：主键自动增长，IO写入连续性好

                          3：数字类型查询速度优于字符串

               缺点：1：并发性能不高，受限于数据库性能

                          2：分库分表，需要改造，较复杂

                          3：自增：数据及数据量泄漏

Redis自增   Redis计数器，原子性自增 

                   优点：使用内存，并发性能好

                   缺点：1：数据丢失

                              2：数据量泄漏

雪花算法     分布式ID经典解决方案 

                    优点：不依赖外部组件，性能好

                    缺点：时间回拨

分布式锁应用场景

1：分布式系统集群，JAVA锁已经锁不住了

2：操作共享资源，如库里的唯一的用户数据

3：同步访问，即多个进程同时操作共享资源

分布式锁解决方案

1：redis    setnx  key value 10s 、 Redission  watch dog

2：基于Zookeeper，临时节点，顺序节点

3：基于数据库，如MySql主键或唯一索引的唯一性

redis做分布式锁死锁解决

1：加锁，没有释放锁，需要delete key

2：加锁后，程序还没执行释放锁，程序挂了，需要设置key的过期机制

3：key过期了，但程序还未执行完，锁可能被其它线程抢占。需最加线程判断延续key的过期时长

Zookeeper和Redis分布式锁区别

redis：1：redis只保证最终一致性，副本间的数据复制是异步进行，主从切换之后可能有部分数据没有复制过去可能会发生丢失锁的情况，故强一致性要求的业务不推荐使用redis，推荐使用zookeeper

            2：redis集群各方法的响应时间均为最低。随着并发量和业务数据量的提升其响应时间会有明显上升，极限qps可以达到最大且基本无异常

zookeeper：1：使用zookeeper的临时顺序节点，临时顺序节点的生命周期在Client与集群的Session结束时结束。因此如果某个Client节点存在网络问题，与ZooKeeper集群断开连接，Session超时同样会导致锁被错误的释放(导致被其它线程错误地持有)，因此zookeeper也无法保证完全一致

                    2：zookeeper具有较好的稳定性，响应时间抖动很小。但随着并发量和业务数量的提升其响应时间和QPS会明显下降

总结：Zookeeper每次进行锁操作前都要创建若干节点，完成后要释放节点，会浪费时间，而redis只是简单的数据操作。