@kaiger 这是旧款的无刻 HHKB Type-S ，彩色键帽是单独买的

以前我也纠结过这个问题，始终没有一个完美的方案可以覆盖所有场景，针对不同场景用不同实现比较好。

普通场景允许短时间内缓存不一致的话，一般用 Cache-Aside pattern 。
如果缓存不一致可能带来生产问题，比如，可能造成资损，建议还是用 事务 /分布式锁 方式保证强一致。

Cache-Aside pattern 实现简单，性能也是最好的，很多大厂都在用： https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside

想问一下有转正名额吗？比例是多少？转正之后薪资大概是多少？

怎么聊到 C10K C100K C1000K 了？
并发数和连接数根本就是 2 个概念

我每次节假日回家，家附件的餐饮店都会换几家，加盟店就是纯纯的给总部打工，现在这个情况更不适合，微信公众号找几篇开餐饮店亏损相关的文章吓吓长辈就完事了。

看场景，不需要限制长度 text 和 varchar 都可以，需要限制长度的还是用 varchar(n) 好点。不过，大家工作中都喜欢用 text 梭哈，不用为了长度限制操心

不可能存在 0 warnings 的代码，比如："Return value of the method is never used", "Parameter is never used" 这种是无法避免的，有究极代码洁癖的 antirez 写的 Redis 源码里也有一堆 warnings ，但这不代表就是代码质量有问题，纯纯的 IDE 无法理解

恐怖如斯

强转 Go 是不太明智的选择，如果我是面试官，候选人从其他语言转 Go 没写过生产项目，那大概率是低录用优先级。

最好是有一个合适的机会，比如，公司内部有 Go 项目缺人，可以转过去试试水，也不用担心试用期被裁。

可以把文件传到云文件服务，比如：阿里云 OSS 、腾讯云 COS 、Amazon S3 ，最便宜的一年 10 块钱左右吧。

如果有后端服务，且文件比较小，可以通过 HTTP 接口直接返回。

@shilianmlxg
@xiangxiangxiang

复杂度具体要看你们业务需要实现的细节，一般来说前端可能会稍微复杂点，比如：消息重发、消息撤回、消息已读、客户端拉取离线未读消息、客户端过滤重复消息等。后端主要考虑集群高可用、消息 ID 生成算法、消息持久化。

具体的思路就是保持每个服务的实现简单，尽量不引入中间件增加复杂度，Chat API 只负责 CRUD ，Chat Server 只负责消息推送，保证这两个服务可以单独使用互不影响。


因为是给集团设计的，所以不太方便直接拿出来给大家看，现在手头上也没有现成的设计方案，可以弄个语雀文档，把我加进去，我有空把各个功能的细节写一下，大家一起设计。

不需要保存聊天记录的话，直接 websocket + protobuf 就可以了。

如果要保存聊天记录那就复杂了，需要一定的开发成本，推荐使用商业的 IM 解决方案。

如果项目内容比较敏感，需要自己开发一套系统，可以参考这个：
把服务拆成 Chat API 和 Chat Server：
- Chat API：负责 CRUD ，无状态，可以动态扩容，主要性能瓶颈在于数据库。
- Chat Server：负责保持长连接，推送消息，通过注册中心相互发现，或使用 Peer to Peer 方式相互注册和推送消息。
- DB：推荐 MongoDB 之类的 NoSQL

理论上，Chat Server 只需要 2 个实例就可以保证高可用和十万级连接数，只需要传消息 ID ，所以报文很小，使用 protobuf 通常只有 20 - 50 Bytes

https://i.v2ex.co/bN9v765l.png

idea 插件 Maven Helper

边缘计算，人脑领先行业几百万年

好消息，新版本已经弃用 ZIPLIST 了

#define OBJ_ENCODING_ZIPLIST 5 /* No longer used: old list/hash/zset encoding. */

https://github.com/redis/redis/blob/6686c6d774fcf71fffbaeff798c997ab3eff80de/src/server.h#L840

等 JetBrains Fleet

换一个思路不知道可不可行，提供一个 Web 页面，客户提交信息到服务端，然后服务端渲染 PDF 然后再打印，这样就不需要开发客户端了