一次消息队列异常堆积的排查
背景前两天收到业务反馈有一个 topic 的分区消息堆积了,根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。排查通过排查，发现确实是在一点多的时候消息堆积了（后面是修复之后堆积开始下降）。。。
相关分享
嵌入主线程消息循环的任务调度器
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题：如何在主线程事件循环中执行特定任务，同时仍保留原有多线程调度模型。
问题的核心来自图形 API 和平台约束。sokol 并非线程安全，OpenGL 又依赖当前线程状态，而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。
作者的解决思路不是重写整个调度器，而是在 ltask 中“打洞”：让某些必须在主线程回调中执行的 Lua 任务，临时从调度表中移出，由主线程接管执行，完成后再归还给调度器。
文章最有价值的地方，是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读，但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
无图
记一次图片访问异常排查过程
本文总结了一次关于头像图片访问异常的排查过程。用户反馈在某些网络环境下无法查看特定域名的头像图片，经过分析发现问题是由于网络环境对该域名的连接进行了阻断，可能是被误认为广告域名。通过替换域名解决了问题。文章还讨论了SNI（服务器名称指示）在HTTPS连接中的作用及其在拦截请求中的应用。
无图
无图
IM服务器设计-消息存储
这部分专门讲述IM消息存储的设计。消息存储的难度在于，要考虑以下的场景：
1、离线消息存储。即发送消息时对方不在线该怎么处理。
2、单聊、群聊消息。
3、随着用户量越来越大，应该以后如何扩展。
无图
JVM内存问题排查流程
首先确认问题现象，可以通过服务状态，监控面板、日志信息、监控工具（VisualVM）等，确认问题类型：
1、内存使用率居高不下、内存缓慢增加、OOM等；
2、频繁GC：Full GC等；
发现问题不建议重启，留存状态。
无图
使用 SQL 的方式查询消息队列数据以及踩坑指南
为了让业务团队可以更好的跟踪自己消息的生产和消费状态，需要一个类似于表格视图的消息列表，用户可以直观的看到发送的消息；同时点击详情后也能查到消息的整个轨迹。
无图
【死磕 Redis】—– 如何排查 Redis 中的慢查询
我们知道 MySQL 提供了慢查询日志帮助我们定位系统存在的慢操作，同样在 Redis 里面也提供了类似的功能。所谓慢查询日志就是系统记录那些执行时间超过预设阀值的命令，包括发生时间、耗时、命令的详细信息等相关信息都记录下来。
慢查询的作用：通过慢查询分析，找到有问题的命令进行优化。
Redis 执行命令分为四个步骤：发送命令、命令排队、执行命令、返回结果。需要注意的是，慢查询只统计步骤 3 的时间,所以没有慢查询并不代表客户端没有超时问题。
无图
纯CSS实现未读消息超过100自动显示为99+
未读消息超过100显示为99+是常见的交互，目前主流实现一定是通过 JS 逻辑判断，其实纯 CSS 就能实现一模一样的功能，兼容性还不赖，进来看看吧。
无图
这款网络排查工具，堪称神器！
常用的 ping，tracert，nslookup 一般用来判断主机的网络连通性，其实 Linux 下有一个更好用的网络联通性判断工具，它可以结合ping nslookup tracert 来判断网络的相关特性，这个命令就是 mtr。mtr 全称 my traceroute，是一个把 ping 和 traceroute 合并到一个程序的网络诊断工具。
无图
笔记本电脑电池损耗的排查和电池养护建议
由于笔记本电脑电池采用的是锂电池，手机、Pad等设备也是锂电池，所以计算损耗的方法是一样的。
在历史上还有镍镉电池、镍氢电池，因为效率和体积的原因，目前都已经基本淘汰，3C数码产品基本都是锂电池。
无图