做得很漂亮。看到过好几个人发 redis 桌面客户端了，但是不太明白的是为什么需要桌面客户端啊，redis-cli 不是很好用吗

@Huelse 是有这种需求，但是注意审题啊，是客户端查询。
第一种：本地有存储消息，直接客户端本地搜索啊。
第二种：客户端本地不存储消息，应该是没有什么 IM 应用会在所有会话中查询某个关键字吧，而是在某个会话里查询，直接拉取某个会话的历史消息来搜索，不就可以了？

当然也会有在后台查询关键字的情况，多半也是会指定某两个用户之间消息查询。
实在想不出来在所有用户的所有会话里查询关键字这种需求的意义，所以觉得 ES 没有适用场景。

“频繁的查询聊天数据”

其实很多是无效请求，根本没有新增消息，可以在 redis 中设置标记，真正有新消息时才去读取 DB ，可以很大成都降低 DB 压力。

说用 ES 的真是人才，还全文索引。。。

“客户端需要频繁的查询聊天数据” 意思是用户需要拉取和其他用户会话的聊天消息，而不是去全文索引查询某个关键字。
mongodb shard 再适合不过了，设计好 shard key ，保证两个用户之间的会话消息落入某一个分片中，不同的会话消息均匀分布到各个分片。比如 {sessionId: "hashed", msgId: 1}，如果有群聊天也是一样的，分配一个 sessionId ，msgId 递增，以支持按会话批量按序拉取消息。

再设置一个字段自动过期删除。

我们游戏项目在用，爽的很

万事开头难。我一直做后端，js 、html 、css 什么的之前都没有接触过，然后大概看了 2 周的基础知识，就开始基于 vue-element-admin 开始撸了，头一周磕磕绊绊的，往后就感觉好多了。 感觉 vue 让前端开发太容易入门了。

@Nitroethane 感谢，另外一个程序没有用 c 库，

“基本不可能单手拿起，两个手才能把电脑从桌上“抠”出来” 这个还真是，以前的方便得多。

之前很多人批的刘海屏感觉还好，软件全屏完全没感觉

@shiftvector 嗯，就是软件问题，单独轻点都很正常。

AccessSvr 存在的意义是啥？为什么用户不是和 proxy 建立 tcp 连接呢？

我现在做的游戏后端，用的 nats 在内部服务之间转发消息。

@JamesChen #29 谢谢，看了文档，确实啊。如果 redis.call 命令有错误会直接抛出异常了，如果执行成功，返回值一定是 True

@enan01 #10 没有这个问题，因为只会在主节点写 redis

@draymonder #13

第一个问题确实存在。
因为本来就会大量用到 redis，所以并没有增加依赖。

不急，再等等。

以上消息发自 MacBook Pro (Retina, 13-inch, Late 2013)

@lysS 没懂你的意思。

我们业务目前没有使用 mysql，不想因为一个 id 生成新增加一个组件。

“不考虑持久化，直接 uint64 自增” 这个分布式环境你咋个自增

@Ariver 集群或者单实例都支持呀，反正只用到了一个 key 。主要是可以规避时间回调问题。

@zhaokun 有道理