UUID
数据库自增长
使用Redis生成ID
时钟算法
变异时钟算法——SnowFlake（雪花）算法
自定义发号机制
分库：将一套数据库的设计结构，部署到多个数据库实例的节点（逻辑节点）中去，在应用的时候，按照一定的方法通过多个数据库实例节点访问数据。
核心：将数据库分为多个节点，所以需要一个路由算法来确定数据具体存放在哪个库中，于是路由算法就成了我们关注的核心内容之一。
查询/操作：最简单的路由算法是求余算法.例如，现在划分为3个数据库，在获取用户ID（userId，假设是一个Long型数据）后，采用userId对3求余（userId%3），得到余数（可能为0或1或2），然后再根据余数存放到对应的库中。当然，这样也会有一定的缺点，为此有人提出了一致性哈希算法。
还有其它的方式：比如Choerodon项目就是每个微服务使用一个库来达到分库的目的
分区：一张表的数据分成n个区块，在逻辑上看，最终只是一张表，但底层是由n个物理区块组成的。
分区技术与分表技术很类似，只是分区技术属于数据库内部的技术，对于开发者来说，它逻辑上仍旧是一张表，开发时不需要改变SQL表名。当前Oracle和MySQL 5.1后的版本都能够支持分区技术。将一张表切分为多个物理区块，有以下这么几个好处。
●相对于单个文件系统或是磁盘，分区可以在不同的磁盘上存储更多的数据。
●数据管理比较方便，例如，需要按日期删除交易记录时，只需要在对应的分区操作即可。
●在使用分区的字段查询时，可以先定位到分区，然后就只需要查询分区，而不需要全表查询了，这样可以大大提高数据检索效率。
●支持CPU多线程同时查询多个分区磁盘，提高查询的吞吐量。
●在涉及聚合函数查询时，可以很容易地合并数据。
分表（不推荐使用）：指在一个或者多个数据库实例内，将一张表拆分为多张表存储。
原因：一张表数据量太大，性能瓶颈（MySQL 5000万条记录左右）
拆分：根据某种算法拆分表，比如交易记录表根据年份拆
查询：分表查找、需要路由算法和合并算法合并数据。
不推荐原因：分表会导致表名变化，产生逻辑不一致，继而加大后续开发的工作量和统计上的困难。
优点：简单方便、性能高
缺点：无法满足较大的伸缩性
实际实践三大问题
优点：对于伸缩性大有好处
缺点：能导致数据分配不均，造成某一节点数据膨胀
热点数据
ShardingSphere的重要概念
强一致性：指任何多个后续线程或者其他节点的访问都会返回最新值。需要复杂的协议，也会牺牲更多性能。
弱一致性：指当用户对数据完成更新操作后，并不保证在后续线程或者其他节点马上访问到最新值，它只是通过某种方法来保证最后的一致性。
优点：实现简单 ，缺点：性能低，死锁
增加询问阶段
增加超时机制
RabbitMQ可靠事件
提高尝试次数
保证幂等性
tcc-interface.png
tcc-service.png
0
0
分享
