今年的10.24程序员节相比往年投入巨大，部门开发了土耳其跳棋(Dama)AI对战平台，可以提交AI并和他人对战，10.24当天凌晨做最后一次匹配对战，按排名发放奖励。奖励很微薄，但过程很有意思。这里对参赛过程做一下回顾。这篇blog不能直接告诉你如何实现一个对弈ai，在阅读了所有引用的情况下，可以作为实现对弈ai的选型参考。

概述我实现了一个供游戏接入的IM系统，这是我为数不多，历时超过5年，持续开发的系统。大部分的坑都是自己埋的，总结一下经验和教训。好的设计session 抽象和 msg 表设计session 抽象对于IM系统，会话是最核心、顶层的概念。会话有如下属性：参与者。消息历史。会话信息。下图中红框部分即会话。举例：用户A to B的私聊...

概述在做mongo建连优化时，突然发现打出的包无法启动。有日志如下： {代码...} 原因是打包机的环境变更，导致： {代码...} 排查过程回滚代码到可启动包代码。重新打包，也无法启动。基本判定是打包机环境变更问题。并找了打包机的管理同学。设可运行包为a，不可运行包为b，对比a, b的差异。a, b包均可在开发环境正常运行...

因为virtualbox中无法使用cuda，见use-host-cuda-from-virtualbox。所以我想到了windows下的wsl，尝试后发现可行，记录一下过程。后面得知，wsl2对gpu的支持是20年引入的：[链接]

调研从redis官网推荐、hex.pm下载中可以看到。有 redix/eredis 供选择。redix vs eredisredix 在如下方面有明显的优势：redix支持链接多路复用。而eredis是poolboy，一个链接同一时间只能阻塞执行一条指令。支持child_spec，后台静默重连，用gen_statem处理重连期间的请求，大部分时候重连无感。telemetry，监控、日志通...

需求打标是个很常见的运营需求。一开始，往往会被简单的实现为数组，之后就是各种硬编码的补丁逻辑。概括一些比较关键的运营需求：标签分多个维度，如，性别和年龄属于不同维度。标签分层级:篮球版块包含NBA，CBA...不同场景，不同的查询规则。反选能力：可以选择儿童，仅儿童可见，也可选择非儿童，仅儿童不可见。按规...

就绪探针 (Readiness)，循环调用，决定服务发现，有没有流量进来（包括INGRESS和DNS，DNS几乎是实时的，当节点滚动更新开始后，到节点就绪探针返回成功前，DNS无法发现对应节点，推测INGRESS也是依赖DNS，所以，同样部署在K8S上的HTTP服务不需要额外增加SLB）。

erlang 的 cowboy 是一个 web server 框架。它在客户端提前断开（nginx http code 499）时，会直接杀掉handler进程。这很容易造成bug。

这个一个耗时2天半的新布署环境线上问题定位。在查到问题后，发现似乎很简单，但为什么定位了2天半呢？原因是：“不知道自己不知道”。这篇blog对排查过程做一个记录。

性能足够快，不希望有单点。鉴于有数据共享需求，没有单点的情况下，erlang中几乎只有ets了。因为ets仅能实现k,v查询，不能实现更复杂的读写需求，比如寻找某个子网(key="192.168.x.x")下的任意IP(values = ["192.168.1.1", "192.168.2.3"])，于是决定用NIF来实现。这是第一次尝试在实际业务中使用NIF。这里做一下总结。

简介profiling工具是语言生态的重要组成部分。这篇blog对erlang的vm层profiling做一个总结。profiling tools overview可参考[链接]名字功能剩余性能）cprof统计模块的调用次数，可找出调用次数热点0.67eprof统计模块的调用次数和时间，可找出调用时间、次数热点0.17fprof统计模块调用次数和关系，可生成call-graph0.008e...

最近升级了otp24，一个提供位置无关call entity的组件在调用的entity进程退出时。会出现timeout。在追查后发现和erlang otp24的一个改进相关。[链接]

线上mongodb主库经常出现以5分钟为周期性的慢查询。在排除业务代码bug，机器cpu/io/memory资源限制后。最终发现是mongodb的bug，因为这是一个非常典型的加锁导致的性能不佳问题。故做一下记录。

在线上遇到了因节点名哈希值冲突导致的部分机器无负载问题。10台机器中，冲突的机器达到了4台之多。假设哈希的概率是平均的。10台机器中，不存在冲突的概率接近

源码版本：[链接]d992fe5318d8d7af9510b879439a3c7f283da442代码里有大量的函数指针，对应不同的协议簇，在看源码的时候必然有很多猜测成分，但最终的结论是可信的，主要是这个实现很合理。

概述etcd提供了线性一致性。在线性一致性的基础上。etcd提供了Campaign 进入等待队列，当前面所有其它候选人的value都delete后返回。Proclaim 不丢失leadership的情况下，重新申明一个新的值。Resign 放弃leadershipLeader 获得当前的的leader valueObserve 开始watch leader value 的变更这篇blog讨论了etcd选举机制的...

概述这篇blog主要探讨常见的分布式一致性算法：paxoszab (zookeeper atomic broadcast)raftgossip重点在于对比这些算法的相同点和差异。思考算法的设计和取舍.paxospaxos是最早提出的分布式一致性算法.见[链接]重要概念Roles实践中, 节点往往同时承载proposer/acceptors/learner的功能.proposer提案人，A proposer sends...

要从一次线上的内存泄漏说起. 最终定位到在异步send方法中, monitor了被调用进程, 而又没有释放, 导致泄漏. 违反直觉的是, 这个泄漏是双向的, A monitor B后, A会记录 monitors B, B会记录 monitored_by A. 进程A退出后, 进程B不会释放 monitored_by A. 所以, 在使用monitor时, 注意在任何情况下, 都要demonitor.

对服务器来说, 在单条链接到达吞吐上限之前. 更少的链接意味着更少的上下文切换, 更少的内存消耗(tcp协议栈内存消耗, 应用层的buffer). 所以, 在常规的索引, 分片, 读写分离之外, 连接池的设计, 对数据库性能也有很重要的影响.我们使用的语言没有官方driver, 连接池的实现采用了固定大小. 在节点不多的情况下问题不大, ...

最近将erlang从otp21.3.8.17升级至最新的otp23.1. 遇到了两个编译不告警, 但版本前后语义不一致, 且在changelist中未提及的问题. 在此做个记录.

http2 web server 在query params过大时，服务端会返回错误码ENHANCE_YOUR_CALM。因为chrome浏览器在version: 86.0.4240.111中的调试窗口没有显示具体的错误码。定位起来没那么直接。

概述不谈profile tools的重要性. erlang profile一定要看看下面这篇.[链接]这篇blog记录一些实操.步骤fprof采集数据在程序中, 或者直接remote_console触发采集. {代码...} 不传递参数情况下, 默认会将fprof信息写入fprof.trace文件.使用kcachegrind 查看fprof的结果使用erlgrind转化为callgrind格式 {代码...} 安装kcach...

有很多场景需要在一系列节点间共享内存数据. 如, 有一系列水平对等的网关, 可以在任意网关节点上拿到所有网关的特定内存信息. 一般的做法是使用zookeeper, etcd等提供了分布式一致性保证的服务. 使用zookeeper, etcd做节点间的数据同步当然没有问题. 但是:

概述线上发现http client偶有非常长的超时. 于是深挖一下erlang httpc 的超时.httpc request 耗时一个http请求耗时包含如下部分创建链接(若没有可用的链接)发送/等待返回在erlang httpc中由如下两个参数控制:timeoutTime-out time for the request.The clock starts ticking when the request is sent.Time is in millis...

一些思考为什么要实现heartbeat为了确认链接, 通信channel是健康的, 为了尽快感知如下情况:TCP FIN包可能丢掉/没有发送网络设备可能出现故障应用出现故障为什么要在应用层实现heartbeat即, 为什么不使用tcp keepalivetcp keepalive 无法检测应用的状态TCP的KeepAlive, 在a 开启对 b 的 keepalive 时, 可以验证: 在a的操...

具体见[链接]先讨论overlay, 近2天排查的是container之间的问题. 记录一下常用的脚本和命令.[链接]下图参考concept使用. 原图来自于[链接]但链接已失效.

tls可以防止第三方的窃听, 纂改, 和重放. 但通信双方, 即alice和bob是知道全部内容的. 所以说, https, 即tls是可以抓包的. 下面总结下几种常见的抓包方式.

监控的四个黄金指标 延迟 流量 错误 饱和度 见google-sre-ebook, 对rpc来说. 我做监控图表时一般是qps/rtt/error, qps对应饱和度和流量(对特定业务做过压测的情况下), rtt(query round trip time)对应延迟。error就不用说了. 监控坑 qps和rtt没有分开counter和histogram 曾经只用histogram做qps和rtt. 这样做的问题在于,...

做了一个索引优化。将3个索引优化为1个。只保留了一个{session_id, create_timestamp}索引，更到线上后未发现大的问题。

看完raft后, 一直有计划通过看etcd进一步学习, 毕竟在生产环境中引入了etcd, 有必要对其更透彻的了解. 在调试etcd时遇到了一些梗. 这里做个记录.