Creat-qc
Creat-qc
docker-compose.yml 里面加上端口映射 80：80，且设置 user：root
我忘了总结问题是什么了，这个问题是 客户端 订阅的 topic 是 gate/HD_chat/face ，然后 服务器端 gate模块 声明的 id是 HD_chat，我知道前面的chat 是表示 模块的id，用于匹配的，我不懂的地方是为什么 我订阅的路径后面多了个face，但是 发送消息的时候仍然可以发送成功，这个没有日志前辈，我截个代码的图你看看。  
session的存储不是需要自己实现吗，这个可以通过 验证 session的连通性 判断，不连通的话就删除记录
最新的提交好像是5月份的
前辈，你是说客户端重连nats嘛，我今天看了下nats的官方文档，上面显示如果断开大多数情况会自动重连，我也没有设置成不允许重连，然后我看了下客户端的启动代码，我是仿照mqant的文档写的，没有对nats的配置 func main() { task := task.LoopTask{ C: 1, } manager := chat.NewManger(task) fmt.Println("chatroom-client启动") task.Run(manager) c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt)
这个项目不是可以直接拿来用的吧，作者只是提供了这样的思路，比如一致性hash可以解决节点变动带来的问题。上到生产环境的话肯定要加以完善的。比如上面说的需要记录各个节点的位置。
peer后面跟的字母没有意义，我理解真正起到节点排序作用的是节点名称hash后的值，这里作者可能只是随便写了几个数字，（不然key2两边为什么会有key11和key23），理解作者的意思就好，我和你对一致性hash的理解是一致的
except KeyError: self._partial = True # TODO: Apply similar perf optimisation as above for partial for key, value in kwargs.items(): setattr(self, key, meta.fields_map[key].to_python_value(value)) 和这里的TODO 有关系嘛，是不是一个已知的问题 @jairhenrique @kianmeng @isaquealves @wolph
好的，我在你们的_init_from_db函数中加上了如下简单的代码注释   下图是日志的打印结果：  我们的models   我们的实际数据库表  可以看出实际数据库与models中的定义是一致的 且通过打印日志发现，正常情况下 map是正确的，但是在异常情况下，会引发不可恢复的致命问题 这是我截取的相关日志  下面是我对tortoise-orm 的相关实现的理解 通过修改源码，打印日志发现，应该是 需要特殊处理的参数 在做映射时出现了 找不到key 从而找不到 本应映射到的 参数类型，进而引发了 keyError问题；tortoise-orm 在处理model时，会做一层缓存机制，也就是将model中的key 应该映射成什么类型进行缓存。所以引发KeyError的本质原因有可能是 缓存中的map 与实际不一致，因此报错，并且在服务重启后，缓存清空，所以重启服务后可以正常运行一段时间。 为什么...