相关分享
嵌入主线程消息循环的任务调度器
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题:如何在主线程事件循环中执行特定任务,同时仍保留原有多线程调度模型。
问题的核心来自图形 API 和平台约束。sokol 并非线程安全,OpenGL 又依赖当前线程状态,而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。
作者的解决思路不是重写整个调度器,而是在 ltask 中“打洞”:让某些必须在主线程回调中执行的 Lua 任务,临时从调度表中移出,由主线程接管执行,完成后再归还给调度器。
文章最有价值的地方,是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读,但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
一次消息队列异常堆积的排查
背景前两天收到业务反馈有一个 topic 的分区消息堆积了,根据之前的经验来看,要么是业务消费逻辑出现问题导致消费过慢,当然也有小概率是消息队列的 Bug(我们使用的是 pulsar)。排查通过排查,发现确实是在一点多的时候消息堆积了(后面是修复之后堆积开始下降)。。。
IM服务器设计-如何解决消息的乱序
IM消息需要面对的另一个难题:如何保证收到的消息不乱序。下面先展开看看要解决这个难题有哪些障碍。
IM服务器设计-消息存储
这部分专门讲述IM消息存储的设计。消息存储的难度在于,要考虑以下的场景:
1、离线消息存储。即发送消息时对方不在线该怎么处理。
2、单聊、群聊消息。
3、随着用户量越来越大,应该以后如何扩展。
“安全”这个热词:应避免使用还是该更直接了当?
当某人标榜应用程序“安全”,以此来吸引你使用他们的产品,产品实际上是在暗示一种承诺:“安全”的含义就是它是安全的,它值得你的使用与信任。但问题是,“安全”这个词可能指的是许多事情,技术行业常将它用作一个过于泛化的术语,以至于它逐渐失去了实际含义。
由于“安全”一词可能含义丰富,也可能一无是处,使用它就需要慎之又慎。事实上,最好是尽量避免使用这个词,取而代之的是,诉诸你真正要表达的东西。
使用 SQL 的方式查询消息队列数据以及踩坑指南
为了让业务团队可以更好的跟踪自己消息的生产和消费状态,需要一个类似于表格视图的消息列表,用户可以直观的看到发送的消息;同时点击详情后也能查到消息的整个轨迹。
如何避免AWS的高额账单?
尽管Serverless架构在某些方面表现出色,但在当前轰轰烈烈的“微服务”进程中,它仍然不是一种主要的选择。除了由于本身特性导致的使用场景受限外,我想乏善可陈的关于Serverless最佳实践的总结也是一个重要的因素。
分布式事务概述
现在手机银行转账已经司空见惯。但是,D瓜哥一直在思考,银卡跨行转账是如何保证事务一致性的?借机就对分布式事务,做了简单地了解。
2PC 两阶段提交(2pc, two-phase commit protocol),2pc是非常经典的强一致性、中心化的原子提交协议。中心化是指协议中有两类节点:一个中心化协调者节点(coordinator)和N个参与者节点(participant、cohort)。
Replication(下):事务,一致性与共识
本文主要介绍事务、一致性以及共识,首先会介绍它们怎么在分布式系统中起作用,然后将尝试描述它们之间的内在联系,让大家了解,在设计分布式系统时也是有一定的“套路”可寻。最后将介绍业界验证分布式算法的一些工具和框架。希望能够对大家有所帮助或者启发。
纯CSS实现未读消息超过100自动显示为99+
未读消息超过100显示为99+是常见的交互,目前主流实现一定是通过 JS 逻辑判断,其实纯 CSS 就能实现一模一样的功能,兼容性还不赖,进来看看吧。
