相关分享
嵌入主线程消息循环的任务调度器
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题:如何在主线程事件循环中执行特定任务,同时仍保留原有多线程调度模型。
问题的核心来自图形 API 和平台约束。sokol 并非线程安全,OpenGL 又依赖当前线程状态,而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。
作者的解决思路不是重写整个调度器,而是在 ltask 中“打洞”:让某些必须在主线程回调中执行的 Lua 任务,临时从调度表中移出,由主线程接管执行,完成后再归还给调度器。
文章最有价值的地方,是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读,但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
IM系统重构到 SDK 设计的最佳实践
本文介绍了 CIM 系统重构为 SDK 的实践,使用 Builder 模式创建客户端,实现了长连接、心跳检测及自动重连等功能,极大简化了消息收发流程。还优化了请求代理,通过 `ProxyManager` 动态管理 URL,提升了代码复用性。集成测试涵盖多服务器重连和消息验证,确保系统高可用性。重构增强了模块间解耦,使 SDK 更易于维护和扩展。
一次产品重构的复盘
本文深入复盘了一次完整的产品重构过程,明确了重构的时机和阶段性目标。重构中主要解决了架构混乱、性能瓶颈和用户体验不佳等问题。具体操作包括重构代码模块、优化数据库查询、引入缓存机制,并通过用户行为数据来调整功能细节。作者还提出了应对重构风险的方法,如建立测试闭环、逐步发布和快速响应用户反馈,以确保重构效果和产品稳定性。
一次消息队列异常堆积的排查
背景前两天收到业务反馈有一个 topic 的分区消息堆积了,根据之前的经验来看,要么是业务消费逻辑出现问题导致消费过慢,当然也有小概率是消息队列的 Bug(我们使用的是 pulsar)。排查通过排查,发现确实是在一点多的时候消息堆积了(后面是修复之后堆积开始下降)。。。
IM服务器设计-如何解决消息的乱序
IM消息需要面对的另一个难题:如何保证收到的消息不乱序。下面先展开看看要解决这个难题有哪些障碍。
IM服务器设计-消息存储
这部分专门讲述IM消息存储的设计。消息存储的难度在于,要考虑以下的场景:
1、离线消息存储。即发送消息时对方不在线该怎么处理。
2、单聊、群聊消息。
3、随着用户量越来越大,应该以后如何扩展。
使用 SQL 的方式查询消息队列数据以及踩坑指南
为了让业务团队可以更好的跟踪自己消息的生产和消费状态,需要一个类似于表格视图的消息列表,用户可以直观的看到发送的消息;同时点击详情后也能查到消息的整个轨迹。
利用 MySQL 的 Binlog 实现数据同步与订阅(下):EventBus 篇
终于到这个系列的最后一篇,在前两篇博客中,我们分别了介绍了Binlog的概念和事件总线(EventBus)的实现,在完成前面这将近好几千字的铺垫以后,我们终于可以进入正题,即通过 EventBus 发布 Binlog,再通过编写对应的 EventHandler 来订阅这些 Binlog,这样就实现了我们“最初的梦想”。坦白说,这个过程实在有一点漫长,庆幸的是,它终于还是来了。
纯CSS实现未读消息超过100自动显示为99+
未读消息超过100显示为99+是常见的交互,目前主流实现一定是通过 JS 逻辑判断,其实纯 CSS 就能实现一模一样的功能,兼容性还不赖,进来看看吧。
使用jscodeshift做自动化重构
在这篇文章中,我们从一个简化了的实际例子出发,描述了为何jscodeshift在某些场景下可以提供的帮助,比如降低大型修改可能带来的影响(而如果影响不可避免,那么如何使其变得不那么痛苦)。随后我们描述了jscodeshift中的一些基本概念和基本的工作方式,并结合之前讨论的例子实现了部分的自动化重构。
