From d8d065a7c71dfe742bbd209ce5394588f8f7ceba Mon Sep 17 00:00:00 2001 From: Xargin Date: Sun, 8 Jul 2018 23:24:20 +0800 Subject: [PATCH] update di --- ch6-cloud/ch6-07-dist-id.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/ch6-cloud/ch6-07-dist-id.md b/ch6-cloud/ch6-07-dist-id.md index 73aaa7a..d2a05b0 100644 --- a/ch6-cloud/ch6-07-dist-id.md +++ b/ch6-cloud/ch6-07-dist-id.md @@ -30,3 +30,11 @@ Twitter 的 snowflake 算法是这种场景下的一个典型解法。先来看 time in milliseconds worker_id ``` + +首先确定我们的数值是 64 位，int64 类型，被划分为四部分，不含开头的第一个 bit，因为这个 bit 是符号位。用 41 位来表示收到请求时的时间戳，单位为毫秒，然后五位来表示数据中心的 id，然后再五位来表示机器的实例 id，最后是 12 位的循环自增 id(到达 1111 1111 1111 后会归 0)。 + +这样的机制可以支持我们在同一台机器上，同一毫秒内产生 2 ^ 12 = 4096 条消息。一秒共 409.6w 条消息。从值域上来讲完全够用了。 + +数据中心 + 实例 id 共有 10 位，可以支持我们每数据中心部署 32 台机器，所有数据中心共 1024 台实例。 + +表示 timestamp 的 41 位，可以支持我们将时间推进到 `2039/9/7 23:47:35`，暂时也够用了。如果不够用，我们就从数据中心 id 中接一位出来，可以用到遥不可及的未来了。