robinfoxnan的专栏

本文设计并实现了一种基于滑动窗口桶的IM网关单账号流量统计方案，采用环形队列结构，支持1秒至60秒灵活分片，兼顾轻量、低内存与分钟粒度统计。通过触发式更新与惰性清理机制，避免定时器爆炸与无效开销，结合配置中心动态调整限流阈值（如真人用户60条/分钟、群组200条/分钟等），有效防御刷屏与消息风暴，适用于高并发长连接场景。

本文实现基于etcd的灰度配置热更新机制：服务实例通过租约注册至etcd，定时续租（15s）并上报分组信息；后台监听分组策略变更，动态更新限流、去重等配置。采用原子指针保证读写安全，支持canary/stable分组灵活切换，实现无重启灰度发布。路径约定清晰，代码可直接落地，适用于网关类服务。

前文论述了WRR 动态加权轮询算法，适合后端网关较少的情况。它有个天生的缺点就是某个IP每次可能落到不同的网关节点上。针对IM的业务需求，最好是用户每次连接都在同一个网关，使用的多终端登录也在同一个节点，这样下行数据扇出动作会比较省力。参考：https://blog.youkuaiyun.com/robinfoxnan/article/details/164269484?spm=1011.2124.3001.6209所以我们自然会想到使用IP哈希方式映射，但是IP映射方式天然会出现负载不均衡的情况。这里围绕IM长连

摘要：记录了windows11下安装prometheus，windows exporter，grafana ；新建仪表盘，绑定变量，新建面板

在亿级用户即时通讯（IM）系统架构中，单数据中心部署早已无法满足海量并发、低延迟访问、异地容灾及区域网络稳定性需求。微信、钉钉等头部IM产品均采用多地域IDC分布式部署架构，通过地域化流量调度与数据属地存储，解决跨地域访问延迟高、单机房故障雪崩、数据同步混乱等核心痛点。

网关后端架构的核心思想：网关只做长连接接入，把消息生产、业务处理向外剥离，做到接入层可以独立大规模扩容，故障不会相互传导。方案3通过独立接收服务收敛MQ生产者，在网关实例数量庞大的场景下，运维与稳定性收益最为突出。

摘要：即时通讯（IM）系统具备高并发、高吞吐、低延迟、强合规的核心特性，海量消息的收发、业务处理与合规审核极易出现链路阻塞、数据不一致、热点过载等问题。传统串行审核、单链路消息处理模式，无法支撑十万乃至百万级并发长连接场景。

本文介绍了在Windows环境下搭建LiveKit视频会议服务器的完整流程。主要内容包括：1)环境准备（安装Go、Git等）；2)获取并编译LiveKit Server；3)配置和启动服务器；4)创建测试HTML页面；5)生成测试Token；6)浏览器测试1v1视频通话。文章详细说明了每个步骤的操作方法，包括配置文件编写、前端页面设计、Token生成等关键环节，并提供了测试过程中的注意事项，如防火墙设置、NAT穿透等问题解决方案。该指南适合开发者在本地快速搭建和测试WebRTC视频会议系统。

安卓客户端消息存储使用sqlite，数据库结构设计。

如果我们使用一个activity来创建程序，来用占位符管理多个fragment切换，这里水一篇最简单直接的做法。

vue-advanced-chat 聊天控件的使用

目前群聊的存储策略是1写多读方案；每个群组一个队列，按时间顺序排列，不区分用户；私聊的存储是写扩散的，每个人都有自己的消息队列，按时间顺序 保存所有的消息，不区分会话；

使用python 写一个秘钥交换的版本

函数执行格式化，因为GO格式化后的内容，毕竟不是在android 和 ios 中可以显示的控件中使用，所以和其他版本的格式化不太一样；通过这些类，开发者可以对文本的不同部分应用特定的样式和属性，从而实现类似的效果。使用上述的结构解析之后，fmt也可以转为对应的span，这些span 是一个一个罗列的小片段，这个函数简单的总结就是一个递归函数，对其中的文本进行格式化处理，不过GO确实没有啥可处理的。那么这里的span 不仅仅是并列的关系，而且还是一个树状的关系，这里。中对文本的某些部分应用特定的样式或行为。

这份文档介绍了 Drafty，一种由 Tinode 使用的文本格式，用于为消息添加样式。Drafty 的目标是在表达能力足够的同时，不会开放太多的可能性以避免安全问题。你可以将它视为将 JSON 封装了一下的。Drafty 受到了 Facebook 的规范的影响。截至撰写本文时，已经存在和的实现。还有一个，可以将 Drafty 转换为纯文本和预览。这样的好处就是在机器人交互时候可以发送一些格式化的文本，而不仅仅是微信和QQ那种无格式文本；

其中把源码放到自己目录下，改其中的函数，将rune类型参数改为string,

在后台服务中，为了提速，我在内存还做了一个告诉缓存来管理用户信息，根据更新通知，或者定时去redis中同步信息，那么在加载或者更新某个用户元素时，要防止并发，这个类在插入时候，可以检测是否存在，并通过回调函数来决定是插入还是更新；这个加锁已经放在插入函数中完成了；2）去数据库或者redis加载；这里就有个并发重复的可能性；1）如果内存缓存没有；3）添加到内存缓存；

默认情况下，生成的js代码中使用number表示int64，这样在具体交互过程中，数据就不精准;具体可以使用[jstype = JS_STRING] 标记让JS按照字符串处理；

与之相比，通常使用的其他导出类型包括 "spki"（SubjectPublicKeyInfo）和 "pkcs8"（Private-Key Information Syntax Standard #8）。"spki" 用于导出公钥，"pkcs8" 用于导出私钥。：导出的是 Private-Key Information Syntax Standard #8 结构，包含了私钥的算法标识和私钥本身。备注：公钥可以导出，私钥不允许导出，所以只能生成秘钥之后，保存共享密钥，用指纹来标记；

优点：以用户为中心比以会话为中心（tinode）的好处就是消息管理更加容易；每个用户的数据相对集中，可以快速的找到并一次性同步给客户；缺点：数据需要存储2份；优点：群聊使用读扩散，存储数据量少；缺点：读扩散，如果用户反复离线与上线，需要读取离线数据，对scylladb压力比较大；

实现了一个简单的任务管理系统，允许用户定义任务和工作者，并将任务分配给工作者进行处理。这个系统旨在提供一个灵活的任务管理框架，可以根据需要动态地添加和移除工作者，以及处理任务。

椭圆曲线加密（Elliptic Curve Cryptography，ECC）和迪菲-赫尔曼密钥交换（Diffie-Hellman Key Exchange，DH）都是现代密码学中常用的技术，它们可以用于安全地交换密钥和加密通信。

打算做一个免费、开源、安全的通信服务，便于二次开发使用的。

在单机模式下，相对简单，认为所有的客户都在同一台服务器上，姑且认为1台服务器可以同时支持1万用户在线，在更多用户同时在线时，则需要集群来实现负载均衡。集群的算法需要解决故障处理以及动态添加的问题，同时需要考虑如何在集群节点间路由数据。

目前大多应用都是手机登录，但是作为开源的一个软件，或者是私有的一个应用，那么使用手机短信接收验证码成本比较高，使用邮箱相对更容易，邮件其实是有格式的，不是随便发一个字符串过去就好了。这里从tinode中取出发邮件的部分做一个测试，如果不报错，就去收件箱接收邮件就好了。

目前开源的聊天软件主要还是使用mysql存储数据，数据量大的时候比较麻烦；我打算使用scyllaDB存储用户的聊天记录，使用golang开发