消息队列（Message Queue）是一种在消息的传递过程中存储消息的机制，广泛应用于系统解耦、流量削峰、数据同步等场景。本文将重点讨论三种流行的消息队列技术的存储架构（RocketMQ、Kafka和Pulsar）以及当前的演变趋势。
随着人工智能领域的不断发展，语言模型也变得越来越重要。在这个领域中，小模型（Small Language Models）正逐渐崭露头角，与大模型（Large Language Models）相比，它们有着独特的特点和潜在的价值。这篇文章主要关注两点，模型的进展，推理的进展，特别是在消费级设备（PC，移动设备）相关的进展。
之前其实已经写过一篇关于RabbitMQ持久化的文章，但那篇文章侧重代码层面的写入流程，对于持久化操作何时发生以及什么时候会刷新到磁盘等问题其实都没有搞清楚，这篇文章着重于关注这些问题。
对队列系统至今出现的各种问题进行总结。这个系统主要是分为这么几个部分：
- RabbitMQ：消息broker；
- Proxy：架在RabbitMQ前面，主要作用是负载均衡及高可用：消息可以路由到后端多个结点，任一结点的异常不会影响客户端；并且可以让RabbitMQ更方便的进行水平扩展；
- 客户端SDK：为了避免让产品方了解AMQP协议的细节（Exchange、bindings等），对标准的RabbitMQ客户端进行封装，只提供两个简单的接口：sendMessage，consumeMessage，并提供配置选项来定制客户端的行为。
应用中有时候会有读取日志文件，并做近实时分析的需求（日志监控等）。但是使用类似Log4j的日志框架，日志文件可能会滚动：老的日志文件重命名成其它文件名（比如以日期为后缀），生成一个与老文件同名的新文件，这时候就需要读取日志文件的线程能够正确区分新老文件，并读取相应更新并且不会漏读数据。当然，这个问题的前提是：日志文件本身只会append，而不会在文件中间写入或者删除。本文主要分享下解决这个问题时碰到的一些问题及解决方案。
根据Java文档描述，ForkJoinPool中一种特殊的ExecutorService，可以执行ForkJoinTask。ForJoinTask可以在运行时Fork子任务，并join子任务的完成，本质上类似分治算法：将问题尽可能的分割，直到问题可以快速解决。对ForkJoinPool来说，与其它ExecutorService最重要的不同点是，它的工作线程会从其它工作线程的任务队列偷任务来执行。
（注：文章里涉及到的代码分析，基于jdk1.7.0_10 Hotspot 64-Bit）
Java同步机制除了内置的synchronized（包含Object.wait/notify）以外，还通过concurrent包提供了多种锁，包含ReentrantLock、Semaphore、ReentrantReadWriteLock等，以及跟Object.wait/notify类似语义的Condition接口。