背景
在设计底层数据库的过程中,通常情况下对于primary id我们使用的是默认的int。
以postgresql为例,常用的integer类型占4个byte,即32个bit。id最高可以达到21亿: https://www.postgresql.org/docs/9.1/datatype-numeric.html
然而在公司发展后,用32位id较为容易溢出,比如阿里amazon的订单ID,按照一个订单对应一个id算,显然一年就远远不止21亿。
这种情况下,扩展ID的位数是可取的办法。postgres也提供了bigint的类型可供直接使用。
然而数据库的数字id存在一个致命的问题:无法扩展到多台master server架构。
举个例子,通常情况下IT公司都会有两个数据中心,然而只有一个是作为主要的,接受外部流量的中心,另一个作为备份中心。两个中心定期切换以满足维护需求。主数据中心通过database sync 比如postgresql的pgsync https://github.com/ankane/pgsync 向备份中心实时备份数据。 这种结构,从根本上来讲,还是单master架构,因为同时只有一个数据中心在服务外部请求,尤其是写的请求。
作为全球化的大公司,通常会有比这个更高的数据中心需求,比如在北京的数据中心处理中国用户的请求,在美国的数据中心处理北美