How to design Auction System
Вставка
- Опубліковано 20 кві 2024
- 具体的文字版可以参阅这个 blog: pyemma.github.io/How-to-desig...
在这一期的视频里面，我们讨论一下如何 design auction system, 类似 eBay 上面的拍卖系统
我们详细的讨论了如下的功能
- highest bid 是如何 maintain 的 (stateless vs stateful)
- highest bid 是如何 broadcast 给所有的在 auction 里面的 user 的 (live comment)
- auction 如何是计时被 execute 的 (cron job scheduling)
涉及的到一些其他的比较 generic 的 component
- 如何采用双层架构来 manage billion 级别的 live connection 以及 message fanout
- 如何实现 DB 和 cache 之间数据的 consistency
- Websocket 和 sever sent event 的对比和适用情况
- read repair 思想的应用
厉害！👍
感谢支持，希望能帮忙多多宣传
感觉有一个可以讨论的点: 这里bid update service如果也是round robin或者randomly assign SSE connections的话, 意味着每个bid update service有可能会需要处理dispatcher的每一条信息, 因为一个bid update service可能handle很多不同的auctions. 根据auction和bid update service的数量, 可以讨论一下shard SSE connections according to auction ID, 这样相同的auction会集中在几个bid update service上. 欢迎大家分享看法
嗯，非常感谢分享; 这里的确是一个可以和面试官讨论的点，使用 round robin，我们可以避免某个 bid update service 被 overload, 但是代价就是失去了 colocate 的性质; 如果 shard by auction id, 我们可以减少 internal 的 communication (因为只有一个 bid update service 会 subscribe 一个 auction), 但是可能会出现 hotkey 导致 overload; 这里关键的点在于能和面试官交流分析不同的情况就好
@@codingmonkey233 感谢回复! 视频信息量很大, 很有帮助! 在 52:48 有一点我不是很清楚; 视频中提到single hot auction key可以被sub partition出去, 这里指的是类似message queue 里面处理celebrity key那种吗, i.e., append random numbers (e.g. 0 ~ 9) to the hot key so they end up in different partitions. 但是数据库里面感觉实际不是很好操作, 比如这个题要确定最高bid还是需要所有partition的信息. 我个人经验的话这种hot write key其实没有特别好的处理方法, 只能从写入端考虑, rate limiting之类的. 具体这个问题也许可以考虑前面提到的batch的思想, 我觉得很好, 比如在auction service 里面 in memory batch 100ms or 1000 bids, whichever happens first, 提前reject掉一些低的bid, 只取最高的bid尝试写DB.
请问下23:00讲的那个单词叫什么？lease还是list？听懂了是类似于一个version number的东西，但是没听清那个单词叫什么
是 lease，这个是一个比较经典的用来解决 prevent stale write to cache 的方法 (同时也可以解决 herd effect)，可以参考这篇 Facebook 的 memcached paper: www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf 的 3.2.1