提到实时数据库，很多人第一反应是工业控制、航空航天、金融交易这些场景。这类系统有个硬性要求：数据必须在确定的时间内完成更新和查询——这就是所谓的“硬实时”。
eXtremeDB 是一款典型的内存实时数据库，使用 C/C++ 开发，支持事务、索引和持久化，并且提供 C++ 原生接口。关键的是，它没有守护进程，直接嵌入到应用进程里，延迟做到微秒级，这才是嵌入式实时数据库该有的样子。
C++ 接口与模式
eXtremeDB 提供了一个代码生成工具，基于类定义文件（类似 struct）自动生成 C++ 类和方法。你只需要定义好 schema，比如用户的字段，工具直接帮你生成 User 类和 UserDatabase 类，里面包含 insert、update、select 这些常用方法。查询时可以用游标，也可以走哈希索引或树索引。内存分配由数据库自己的分配器管理，彻底绕开了 GC 的不确定性——这对于实时系统来说，基本算是一道护身符。
事务与 ACID
eXtremeDB 支持 ACID 事务，不过它采用的是乐观并发控制（OCC）。简单说就是：写操作如果发生冲突，会直接返回失败，由开发者决定是否重试。C++ 代码里，用 database->begin() 开始事务，操作完后 commit()。如果 commit 返回 FAIL，说明有冲突，重试逻辑由你自行实现。针对实时要求严苛的场景，还可以给事务指定优先级，确保关键任务优先执行。
实战：证券交易系统持仓管理
说一个实际案例。某极速交易系统采用 eXtremeDB 管理用户的持仓数据，字段包括股票代码、数量、冻结数量。系统每秒要处理数千笔成交回报，每一笔都需要实时更新持仓。
C++ 的实现方式：先定义 Position schema，主键设为 account_id + stock_code，并建立 account_id 索引。接着建立内存数据库，并在启动阶段预分配好足够的内存空间，避免运行时的动态分配带来的不确定性。成交回报线程启动事务，查询当前持仓，更新数量，然后提交。如果发生冲突，等待 10 微秒后重试。而查询线程（比如行情推送）使用只读事务，完全无阻塞。
实测下来，单节点每秒可以完成 8 万次事务，延迟控制在 50 微秒以内。这个性能水平，普通关系库很难直接对标。
持久化与恢复
eXtremeDB 的持久化通过 checkpoint 和 transaction log 实现，可以异步写入磁盘。C++ 中调用 checkpoint 方法触发，且不会阻塞实时事务的处理。系统重启时，从最后一个 checkpoint 恢复，数据不丢失。这套机制保证了在兼顾实时性的同时，也不会牺牲持久性。
与其他数据库的对比
简单说几组对比：
- SQLite：速度不错，但锁机制可能导致延迟尖峰，不适合硬实时场景。
- Redis：网络开销是硬伤，epoll 的延迟波动也很难保证确定性。
- eXtremeDB：嵌入式架构、确定性延迟，这才是真正为实时系统设计的数据库。
总结
C++ 在 eXtremeDB 中的应用，本质上是把语言的底层控制力与数据库的确定性的交付结合到了极致。对于高频交易、电信信令处理这类需要极端性能和可靠性的系统来说，它提供了一套已经验证过的基础设施。虽然学习曲线不低，但在关键任务领域，几乎无可替代。
