ccqy66

有一种事件是通过 idl ，不过前提是前后端通过 idl 来定义协议

先把自己想做的东西，拆清楚，搞出一个 MVP 版本，第一阶段目标先上线。后面再慢慢的填坑。

看要解决啥问题？
方案一：如果数据量比较大，影响了查询效率，但是瓶颈并不在数据库本身。
方案二：瓶颈在数据库本身，需要拆成多个数据库实例，提高并发量。

先解决主要矛盾，再解决次要矛盾。
如果现阶段不需要靠工作为生，而且也不在乎这个事情，那就怎么开心怎么来，先以游戏为主，在不影响游戏的前提下留出时间来工作。
如果现阶段需要以工作为生，而且还想搞点事情，那就先以工作为主，可以先尝试不玩，发现还有时间，那就可以看看直播，如果还有时间，那么小玩一把？

我记得 redis 的作者曾经说过：如果 reids 用作缓存使用，不建议使用多 db

说一下个人的理解吧：
AOF 缓冲区的作用：目的是维持主线程 AOF 文件的正常写入，保证在重写阶段，AOF 文件写入的逻辑不变。
AOF 重写缓存区作用：目的是记录 AOF 重写开始之后的键增删改的命令。
这两个缓冲区缺一不可。具体原因如下：
AOF 缓冲区的内容会根据 appendfsync 策略的不同而不同，如果 appendfsync=always，那么每次命令都会立即被刷入到磁盘里，可能 AOF 缓存区就没有数据。而 AOF 重写缓存区一定是从重写开始之后所有的键增删改的命令。两个缓冲区从存在意义上来看是完全不一样的，前者侧重于功能，后者更加侧重于备份。

本质上浏览器上能看到的内容是 http 响应的渲染。只要拿到 http 响应。什么技术都没有用。

@michaelcheng 业务也还算熟悉，只是没有热情去深入业务本身，需求什么的也很快能够完成，所以大部分时候会花时间研究技术，很多前辈也都说在公司向往上走肯定也需要在业务上有些成就