系统设计总结
系统设计的题目，感觉不用做非常多，但要善于总结，相似的问题可以总结成一类，用一个模板来解答，然后加一些小细节加以区分。 如何将一个信息同时传播给多个关注该事务的client 定时任务 Event Sourcing Event sourcing就是说我们不存最后的状态，而是把每一个action都存起来，然后需要结果的话，我们得到所有的action，然后derive出最后的状态是什么。那什么时候需要event sourcing呢？跟钱打交道的时候，比如说Auction system需要我们prove为什么是这个人赢得了最后的bid等。另一个就是，如果很多人都在竞拍一个产品，如果我们只存最终结果（在这种情况下是update Auction表里的winner），在高并发的情况下会一直修改同一个数据，这要比往bid table里不停append给bid table的的性能要差很多。 Lease机制 Lease机制是facebook设计memcached的时候，为了解决数据一致性的问题解决的，非常适合高并发场景。那么是如何工作的呢？– 同一个cache key，memcached维护一个当前有效的lease token，不管多少请求都拿到这个token– server A和server B都来读取数据，拿到相同token，然后server A先过来更新– Memcached对比了token，有效，就把对应的值改掉，lease token也发生了变化– server B再过来更新的时候因为token invalid，所以更新被拒绝 确保任务不会被重复执行 这是经典的分布式系统并发控制问题。例如，a cluster of worker nodes会不停的扫描数据库来发现下一个要做的task。如何保证node A take该task之后，别的node不会重复去执行呢？ 这是悲观锁方案 这是乐观锁方案，用的CAS, 基于version。也可以基于时间戳，设一个last_modified column。 两个方案各有利弊。如果是高冲突环境下，悲观锁比较好，skip locked可以避免无效等待，每次查询基本都可以获得结果，不需要不停的retry。低冲突环境下，乐观锁比较好，没有锁开销，并发读取效率比较高。…