f**********3
发帖数: 295 | 1 设计一个系统，每次请求返回一个唯一的id，要求对大部分的请求做到后面请求的id要
比前面的大，要平均每秒能处理10000个请求，而且请求来自全球。 |
b*****o
发帖数: 715 | 2 返回server当前时间作为id。
【在 f**********3 的大作中提到】
: 设计一个系统，每次请求返回一个唯一的id，要求对大部分的请求做到后面请求的id要
: 比前面的大，要平均每秒能处理10000个请求，而且请求来自全球。
|
A******g
发帖数: 612 | 3 这是我提出的一个方案，被毛子否了，说不能scale，分布式的话，不能保证每个
request当前时间不一样。
【在 b*****o 的大作中提到】
: 返回server当前时间作为id。
|
g*********e
发帖数: 14401 | 4
尾巴上随便加个随机数？
【在 A******g 的大作中提到】
: 这是我提出的一个方案，被毛子否了，说不能scale，分布式的话，不能保证每个
: request当前时间不一样。
|
f**********3
发帖数: 295 | 5 也想过这个，然后毛子说有没不浪费数字的，比如用了1，下一个最好是2，不要就跳到
200了。感觉毛子是明黑
【在 g*********e 的大作中提到】
:
: 尾巴上随便加个随机数？
|
i********s
发帖数: 22 | 6 G家的spanner用到了相关技术。
大概说的是TrueTimeApi，基于GPS和atomic clock在不同数据中心同步时间。
细节看得不是很懂。 |
l*******g
发帖数: 82 | 7 你知道UUID这个么？如果id没有要求一定是number的话，uuid就可以达到scale。wiki
一下就行。
设计一个系统，每次请求返回一个唯一的id，要求对大部分的请求做到后面请求的id要
比前面的大，要平均每秒能处理10000个请求，而且请求来自全球。
【在 f**********3 的大作中提到】
: 设计一个系统，每次请求返回一个唯一的id，要求对大部分的请求做到后面请求的id要
: 比前面的大，要平均每秒能处理10000个请求，而且请求来自全球。
|
f**********3
发帖数: 295 | 8 spanner是全球同步，但不是瞬间同步，拿一个ID同步一次的话，用户不知道要等多久
了。
【在 i********s 的大作中提到】
: G家的spanner用到了相关技术。
: 大概说的是TrueTimeApi，基于GPS和atomic clock在不同数据中心同步时间。
: 细节看得不是很懂。
|
l*********b
发帖数: 1541 | 9 比较模糊。10000请求每秒的话，一台机器就能搞定吧。只有cpu和网络的overhead。
就你说的情况来看，用时间倒是不错的方案。估计还没搞清楚面试官想问的方向？ |
p****U
发帖数: 109 | 10 用一个master/ 队列 接受所有请求， 然后把请求分配给cluster， cluster里面每个
node里都有一个 8bit 的代号。 然后每个node 返回 这个node的8bit代号和按进来的
顺序生成的number。 例如1号机受到第1个从 master 传来的请求 那这个 id 应该是
0000000100000001. 不知道是否ok， 但是每秒10000请求这种东西肯定要放一个 无锁
message queue里吧 然后当做streaming的 派送给各个分机。 |
|
|
b*****o
发帖数: 715 | 11 那就分2步来。
有一个ID server专门负责分发ID（它只有一个状态，就是当前最小的可用的ID），以
及N个负责处理用户请求的request server。用户只和request server联系，而request
server可以根据需求和ID server联系。
当request server没有可用ID的时候，就向ID server申请一批新的ID（比如1K个），
同时ID server更新最小的可用的ID的值（＋1K）。当request server还有ID可用的时
候，就用自己local的ID段处理用户请求。
这样子的设计，从长期来讲ID基本保持是递增的。
【在 f**********3 的大作中提到】
: 也想过这个，然后毛子说有没不浪费数字的，比如用了1，下一个最好是2，不要就跳到
: 200了。感觉毛子是明黑
|
p*****3
发帖数: 488 | 12
抛个砖头吧。
假设一台机器精确到1msec, 每秒可处理1000个request, 那么10000/s需要10台机器。
首先需要同步10台机器的时间(GPS之类的)，否则时间都不一样没法保证先后顺序啊。
既然每秒10000个request, 那么可能在同一毫秒时间内不同机器同时收到request, 那
么就这么编号:这样如果时间顺序有差不管在同
一台机器还是不同机器上id顺序都可以保证，时间相同id也不会重复,还是
decentralized,根据request rate来看，不说完全不浪费，id不会跳跃太大。 time
synchronize也不用每个request就同步一次，10分钟同步一次。再说那些request时间
差个1，2毫秒估计也没啥问题，网络延迟啥的比这玩意厉害多了，没必要那么strict
【在 f**********3 的大作中提到】
: 设计一个系统，每次请求返回一个唯一的id，要求对大部分的请求做到后面请求的id要
: 比前面的大，要平均每秒能处理10000个请求，而且请求来自全球。
|
g*****g
发帖数: 34805 | 13 这也是我提的方案，ID server维护的是一个数据库，每次到数据库里做个
transnational加法。
这样机器当了至少到哪里了还知道。
request
【在 b*****o 的大作中提到】
: 那就分2步来。
: 有一个ID server专门负责分发ID（它只有一个状态，就是当前最小的可用的ID），以
: 及N个负责处理用户请求的request server。用户只和request server联系，而request
: server可以根据需求和ID server联系。
: 当request server没有可用ID的时候，就向ID server申请一批新的ID（比如1K个），
: 同时ID server更新最小的可用的ID的值（＋1K）。当request server还有ID可用的时
: 候，就用自己local的ID段处理用户请求。
: 这样子的设计，从长期来讲ID基本保持是递增的。
|
p*****3
发帖数: 488 | 14
这个只能dedup,怎么保证不同机器能根据时间先后产生出id递增的方案呢？
【在 g*****g 的大作中提到】
: 这也是我提的方案，ID server维护的是一个数据库，每次到数据库里做个
: transnational加法。
: 这样机器当了至少到哪里了还知道。
:
: request
|
p*****2
发帖数: 21240 | 15
一台machine handle 10k毫无压力
【在 p*****3 的大作中提到】
:
: 这个只能dedup,怎么保证不同机器能根据时间先后产生出id递增的方案呢？
|
p*****2
发帖数: 21240 | 16
ID server保证。
【在 p*****3 的大作中提到】
:
: 这个只能dedup,怎么保证不同机器能根据时间先后产生出id递增的方案呢？
|
p*****3
发帖数: 488 | 17
不知道怎么保证，如果给machine 1分 1-100范围的，给2分200-300的，那么就算
machine 2 收到的request比machine 1早，产生的id也会大
【在 p*****2 的大作中提到】
:
: ID server保证。
|
p*****2
发帖数: 21240 | 18
要求对大部分的请求做到后面请求的id要
比前面的大
【在 p*****3 的大作中提到】
:
: 不知道怎么保证，如果给machine 1分 1-100范围的，给2分200-300的，那么就算
: machine 2 收到的request比machine 1早，产生的id也会大
|
p*****3
发帖数: 488 | 19
So???
【在 p*****2 的大作中提到】
:
: 要求对大部分的请求做到后面请求的id要
: 比前面的大
|
l*********u
发帖数: 19053 | 20 这个应该可以。
【在 p*****3 的大作中提到】
:
: So???
|
