如果你觉得直接用 hashmap 太耗内存，那么就在发消息式给个再当前消息内部有效的自增 ID，redis 这边就能用 bitmap 来存是否已读了啊，查的时候直接取出哪些位置没读，然后结合消息 ID 就直接能查除用户了，这个应该式最省内存也不是很消耗性能的方式了吧

@jacobsun #5
@wennew #8 set 操作比直接用 hashmap 麻烦吧，而且直接写数据库就是了，redis 就是个缓存，统计已读有问题不是写已读数据有问题

其实直接发的时候都把发送用户 ID 己到 redis 消息 ID 对应的 hashmap 里就是了啊，读了就从里边删了，看哪些用户没读直接读整个 hashmap 就是了，设置一个合理过期时间也都不用清理，读不到再从数据库加载就是了，发消息和读消息都先写数据库再写 redis 就是了

@TypeError #112 别太认真，其实跌个 30%、40%、50%啥的，国家根本无所谓，反正也不会影响经济基本盘，对国家重要的是只要控制着别跌太快就行，反正明年后年又涨回来了，人家才不怕呢，再说吧你以为今年行情是疫情结束经济向好股市涨么，想多了

@wqhui #136 去年底就感觉年后要杀估值了。没啥大跌的理由。。其实理由感觉不少，不穿 3300 能刹得住的可能似乎比较小啊

感觉可以 320

非常建议用队列，虽然协程性能完全够，但是不能重入啊，重启崩溃啥的都坑死个人

这个应该”是看待个鬼，人家商业公司，自己服务爱收费的就收费关你啥事，爱用不用滚”


@123jiayue #24 我觉得应该来个关键词屏蔽，禁止发这个，又没收他钱，谷歌想咋样就咋样，天下没有免费的午餐，关他啥事，看待个锤子

flutter web 的 canvas 渲染是编译成接近原生的 wasm 的，如果用 js 在 canvas 上绘制，想做出比现有浏览器渲染效率更高还是比较有难度的

@devswork #7 但是高性能的软路由其实就是服务器，同样很占地方，普通的当开发机确定不会影响开发效率？

实在不行随便弄台电脑当服务器也行啊，反正现在单渣主机电脑也不贵吧，软路由真是。。

@lesismal 协程就是在线程池的基础上封装来的，要啥协程池，再说基础架构不意味着就提供一个很丑的接口，既然协程的消耗本来就很低，为了简洁性可靠性抛弃 callback 直接提供协程接口是完全有必要的，再说既然都需要再在 callback 基础上封装适配协程，你这高性能岂不是白白浪费了，现实场景中只通过 callback 转发数据不使用协程的情况几乎不存在吧

go 辛辛苦苦做了协程解决异步化编程难题，然后你又把他变成 callback 了。。。

其实吧相对于带来的编程简洁性协程带来的性能消耗还是值得的，追求极致性能不管编程便利性真的那么重要么？

@AA5DE3F034ACCB9E #21 这个世界没有明文规定但是又允许的事情不是很多么，再说规定也是对租车公司的规定，也许是发给了租车行，不公布也没啥啊，重要的是是否真的方便又不存在重大漏洞损害大众利益

国内有很浓重的应该先有法规再才能这么干，但这其实是根本不合理的，法律法规的出现应该是把符合大众利益的行为公开规定下来并且堵上可能存在的漏洞，是后置的

@mrhhsg #7
@viosey #11
@AA5DE3F034ACCB9E #17

估计租车应该是有特定规定渠道的，就像出租、滴滴专车这样的，整天在路上跑难免意外情况多，12 分显然不够扣吧，租车也是人都离开了很可能不在以城市了，忽然发现违章了，让别人回来处理显然不现实，所以很可能是和交通局统一走的流程，毕竟就算他们能卖分，神舟这种那么多车也不太可能弄到那么多分卖吧，就算真能弄到也早被交管局盯上了

更可能的情况是交管局规定租车行审核违章信息不是明显故意瞎来的，并且分数在 3 分及以下的可以交罚款抵扣，当然交罚款的时候交管局肯定也是要再看是否合理，其实大部分估计也就是租车路不熟意外违章，也不是故意的，再要回去处理确实不合理，这个应该算是人性化管理才对

你提出来反馈好就进入下一个流程了啊，你要做的是尽量分好类，交互问题、流程问题、需求不一致问题等等，做好追踪是否修复就好了，及时给领导开发产品反馈进度就好了，开发不改本来就不是你的问题吧，否则这领导也太推卸管理责任了，要不要改怎么改啥时候改本来就是领导的管理责任，他不能推卸责任啊

流媒体门槛有点高的，所以想做啥呢？但是楼主真是厉害，这么多东西都自己实现了

时效性也妥妥的毫无问题