交易应用程序权衡：数据库和低延迟
几乎每个业务应用程序都需要数据库来存储数据以及针对该数据完成的事务。交易通常需要几毫秒的时间。同时，在交易应用程序中，根本不可接受的一件事是“延迟”。那么，在此类需要延迟上限的应用程序中需要进行哪些权衡呢？
例如，客户已经进行了一笔交易，它必须通过一些检查，这些检查存储在数据库中，需要数据库获取。然后，交易应传递至 OMS/ORS 或交易所。而且，在每一层，都需要在数据库中存储某种交易数据。如何在事务持久性和低延迟之间保持平衡？
Databases are required for almost every business application to store data and the transactions done on that data. The transactions typically take a time of the order of milliseconds. At the same time, in a trading application the one thing which is not at all acceptable is "latency". So, what are the trade-offs made in such applications which require an upper limit on latency?
For example, a trade has been placed by the customer, it must pass a few checks, which are stored in the database, requiring a DB fetch. Then, the trade should be passed on to an OMS/ORS or the exchange. And, at each layer, it would be required to store some sort of transaction data in the database. How should one maintain a balance between transaction persistence and low-latency?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
两件事：
Two things:
如今，人们使用内存事务系统，因此可以减少数据库带来的网络延迟。
这里有一些你可以考虑的低延迟的事情
- 尝试减少争用使用免等待算法(这有点困难），无锁算法。您可以找到大量的示例
- 使用内存计算。内存很便宜，内存中可以存储万亿字节的数据。
-使用机械同情-参考lmax Disruptor，优秀的框架
Now a days people use in-memory transaction system, so you cut down network latency that you get by database.
Here are some things that you can consider for low latency
-Try to reduce contention use wait-free algo( which is bit difficult), lock free algo. You can find tons of example for that
-Use in-memory computing. Memory is cheap, you can have tera byte of data in memory.
-Use mechnical sympathy - Refer lmax disruptor, excellent framework