2019-10-07老师：目前有没有什么不错的开源IM项目可以学习和研究？作者回复: 可以看看mqtt的github项目，另外国内应该蘑菇街开源了一款叫teamtalk的im软件，也可以看看。
6
2019-10-07老师，如果遇到ddos攻击，有啥处理方案吗？作者回复: 硬件层面可以上硬件防火墙来清洗异常流量，软件层面可以通过缩短syn半连接的超时来缓降。
3
2019-10-07老师的课程应该是最近半年极客时间最棒的啦！其他的竟是些概念理论的泛泛而谈😜作者回复: 欣慰，感谢支持，继续努力～
1 3
2019-10-07可以分库分表来解决单表写入数据量大，查询时间过长，但实现其复杂性也增加了，需要实现分区键或者说以什么依据来进行分库分表作者回复: 嗯，分库分表是一个有效提升写入能力的手段，除了这个还有其他优化方式吗？
1 2
2019-10-11是否可以先在服务器端聚合一段时间的数据再写入作者回复: 嗯，不错的想法，业务允许一定的风险的话这是一个不错的优化手段。
1
2019-10-07人数统计的话，应该用redis就可以实现，写入的话，可以队列，异步去写作者回复: 嗯，redis作为计数没问题的，不过异步写入只是起到削峰填谷的作用，并不能提升写入的绝对能力，可以再想一想哈
1
2019-10-07要想解决资源层的写入瓶颈，除了分片机制外，还可以移步写 用队列来操作作者回复: 是个方案，不过队列更多起到的是削峰填谷的作用，对写入瓶颈的真实写入能力提升有限。
1
2020-01-16在连接的前端机对进出直播间事件做初步统计，定期将统计结果刷入缓存，多次进出可以变为一次更新
2019-12-04分表 存贮 对于一些热点列 在cache里面增加特殊索引字段 也可以在内存中 直接存储计算结果 节省 查询 计算时间
2019-11-12请问老师：长连网关调用业务层为何是RPC，而不是通过消息队列调用呢？作者回复: 如果发送消息是否成功依赖于消息存储是否成功，而消息存储的逻辑在业务层，那么发消息需要业务层明确告知是否存储查成功，这种情况rpc通过response明确告知网关层是否成功实现上更方便。
1
2019-11-04要想解决资源层的写入瓶颈，除了分片机制外，还有什么办法能解决资源写入瓶颈的问题呢（比如直播间观看人数的计数资源）？
1.使用高性能缓存。。
2.请求合并- 2019-11-041.连接层和业务层之间增加一个业务代理，这样连接层可以更加专注于处理连接问题，让业务代理来完成服务发现，管理业务集群，这样会不会更好？
2.为什么在连接层直接rpc调用业务端。那业务端需要通过这条连接推送消息不是会很不方便吗？作者回复: 服务发现本身是rpc框架自带的通用特性，对系统消耗很小，再增加一层会使消息收发链路变长，整体稳定性可能会有影响。
业务层推送消息是通过消息队列来实现的，不需要依赖rpc。 - 2019-10-13请问老师，课程中的 tcp长连接网关机，可以用 openresty 开发吗？
作者回复: 对openresty了解不多，据我所知openresty主要是对标nginx的吧，tcp连接相关的信息不知道是否会暴露给使用者，另外即使可以长连接基于它实现可能得大量的lua嵌入开发吧，实现上可能会比较困难。
2019-10-10老师问题:单位时间时间内如何提高写入速度
垂直方向:
1、sql语句优化，索引，事务写入
水平方向:
1、分库分表
2、读写分离
直播观看计数资源，不是要保存在关系数据库，可以考虑用nosql非关系数据库展开
2019-10-09用分片来做水平扩展的话灵活性是低的吧，是不是不适合随着每天波峰、波谷来调整？感觉只能扩很难收。
如果某个时段有大量写入，用什么方式应对比较合适呢？作者回复: 跟随流量波动来进行资源层的扩缩容对于数据读取可能比较有效，但是对于数据依赖master的写入扩缩容实现会比较麻烦。对于写入的优化可以采用类似操作系统buffer的机制，来对写入数据进行合并后批量写入，甚至根据业务来进行更高级的定制化合并逻辑。这一块我在第20篇万人群聊系统的设计中会讲一下。
- 2019-10-08老师，线上netty经常抛java.io.Exception:Connection reset by peer异常，连接被重置，这个问题可以修复吗？
作者回复: 这个是由于对端客户端关闭连接时发送的是强制关闭连接的rst包而不是正常关闭的fin包，注意观察客户端是否对应的有crash的情况出现，一般对服务端连接层没啥影响。
1