Q: 要求eventual consistency。专门用一个count table来存每个post/video的like 数量来 denormalize。然后用一个cache放在前面。重点是不是应该主要是怎么保证cache和db的consistency。还有什么特殊的考点和重点你能想到吗？
A: 这个题目需要专门的 Count Table 和 Count Cache 是对的，不能和 Post Table 放在一起。对于这类应用，一般不需要保证点赞数实时正确，有延迟是可以的，所以 Cache DB Consistency 并不重要。Cache 可以用 write-back cache，读写都通过 Cache，用 Redis 就好。
谢谢老师解答。还有几个问题：
- 一般这种系统需要有一个table来记录谁like了什么post，类似于user_like_post table，这个table需不需要cache放在前面呢？在被大量write的情况下是不是也应该有一个cache？
- 如果是write-back cache的话，需要用什么cache invalidation scheme来让cache里的data不会过于stale，尤其在一个post/video突然变得段时间很多人like的情况下？
- 对于一个post/video突然变得很火, 那个post/video的cache被大量的write，那会不会也把对应的db shard也给load过度呢？这种情况一般怎么处理？
- 需要这么一个表，但是 Cache 不必须，因为 Cache 是解决读的问题的。User Like Post Table 是写多读少。
- 不需要 invalidate，因为所有读写都是通过 Cache的，不会Stale.
- 写的 Traffic 会被 Cache 吸收，Cache 回头写到 DB 可以慢一点也没关系，所以不容易 overload。Cache 倒是可能 Load 过大，所以 Cache QPS 需要做监控，考虑用 Replica 来 serve traffic.
我觉得这个题也想问pre-aggregate吧？为了减少cache的load，我们可以在web server端先进行 videoId based like aggregate，每个一段时间再写到write back cache中，大家觉得这个idea怎么样？
一般不会这么处理，like count 实时性要求还是比较高的，aggregate 会影响 latency，而且增加系统复杂度。
我一直觉得like count 和 monitor system里面的exception count有类似之处，我记得一般的monitor system里面都会有aggregate 。这个的需求是对实时性要求比较高，所以不需要pre-aggreagate了？
对于write back我有个问题，write back cache是什么时候写回DB的呢，这个是具体怎么实现的呢？
是有个单独的worker thread 线程过一段时间扫描一下，把cache中的update写回DB？这个update是通过last update time stamp 比较以后发现的？
这个如何高效的实现 write back，我暂时还没有完全想清楚，想听听老师的想法。
对，主要区别就在这里