谢谢！
分布式应用中，消息系统被大量使用，主要原因有：
1、逻辑解耦：发送方和接收方不需要相互知道对方，一个只管发，一个只管收，大大简化了处理逻辑。
2、适配动态流量：如果发送方发送速度快于接收方的接收速度，消息系统就可以暂时将无法处理的消息缓存起来，让接收方慢慢处理。
没有消息系统时，发送方就不得不配合接收方降低处理速度，从而拖慢了整个系统的性能。
那么消息系统能保证消息100%可靠到达吗？
答案是否定的。
因为消息系统是网络调用，只要涉及到网络，就不可能100%可靠，因为通信双方不可能无限次给对方发ACK确认。
那么消息系统如何尽可能保证消息的可靠达到呢？
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题：如何在主线程事件循环中执行特定任务，同时仍保留原有多线程调度模型。
问题的核心来自图形 API 和平台约束。sokol 并非线程安全，OpenGL 又依赖当前线程状态，而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。
作者的解决思路不是重写整个调度器，而是在 ltask 中“打洞”：让某些必须在主线程回调中执行的 Lua 任务，临时从调度表中移出，由主线程接管执行，完成后再归还给调度器。
文章最有价值的地方，是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读，但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
背景前两天收到业务反馈有一个 topic 的分区消息堆积了,根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。排查通过排查，发现确实是在一点多的时候消息堆积了（后面是修复之后堆积开始下降）。。。
IM消息需要面对的另一个难题：如何保证收到的消息不乱序。下面先展开看看要解决这个难题有哪些障碍。
这部分专门讲述IM消息存储的设计。消息存储的难度在于，要考虑以下的场景：
1、离线消息存储。即发送消息时对方不在线该怎么处理。
2、单聊、群聊消息。
3、随着用户量越来越大，应该以后如何扩展。
出于利益等原因，许多校园网采取一机一号的管理方式。即一个宽带账号只能由一台规定的设备使用。同时检测共享上网以避免使用路由器或类似方式实现共享。那么这些限制背后的原理是什么呢？
本文简要介绍HTTPS协议是如何保证数据在传输过程中的安全的。
由于是以介绍为主，所以不会涉及细节，而且肯定会有一些错误。如果想要详细了解可自行查阅资料。
为了让业务团队可以更好的跟踪自己消息的生产和消费状态，需要一个类似于表格视图的消息列表，用户可以直观的看到发送的消息；同时点击详情后也能查到消息的整个轨迹。
未读消息超过100显示为99+是常见的交互，目前主流实现一定是通过 JS 逻辑判断，其实纯 CSS 就能实现一模一样的功能，兼容性还不赖，进来看看吧。
Java不得Z？图片
@HiWeb_cc：很好的解释了为什么C++比C更难掌“握”，因为前者更“大”，更难图片!
@卡灵顿的小草：右边应该面向她的对象图片
@我叫程旭元叫我旭元就可以：C#=C++++？
@NereusP：C该反省一下为啥没有对象了
下面我们就来讨论下常用的一些API设计的安全方法，可能不一定是最好的，有更牛逼的实现方式，但是这篇是我自己的经验分享.