KDB+架构
架构图地址
整体逻辑
"""
各个交易所获取到的数据，存到了data feed中，属于一个时间序列数据。
数据被送到feed handler中解析，解析完成后转到ticker-plant，有数据即写日志（更新数据的过程是先更新到日志文件，再更新到自己的表中）；数据更新及备份后，循环发送/发布到实时数据库和所有请求数据的链式订户；工作日结束删除日志文件，创建新的日志文件并将实时数据库保存到历史数据库中，然后实时数据库清除表。
"""
具体
"""
数据Feed
数据馈送可以是任何市场或其他时间序列数据。 将数据馈送视为馈送处理程序的原始输入。 可以直接来自交换（实时流数据），来自新闻/数据提供商，如汤森路透，彭博社或任何其他外部机构。
Feed Handler
对data feed的数据做解析，转换成kdb+能识别的格式数据。可以支持多种语言。详细地址如下
https://code.kx.com/q/interfaces/fusion/
Ticker Plant
捕获初始的data feed，将其写入log file并将这些消息发布到任何已注册的订阅者。旨在零延迟。包括以批处理模式获取数据；
管理订阅，添加和移除订阅者，将table definitions发送给subscriber；
处理EOD(end-of-day)程序
//Tickerplants should be lightweight, not capturing data and using very little memory.For best resilience, and to avoid core resource competition, run them on their own cores.
Log file
从feed handler获取到的q消息作为日志保存下来；用于数据恢复，重启了数据库，则改文件用于恢复至重启前的状态。
//The logging process can run on any hardware and OS, from a RaspberryPi to a cloud server.
Store the file on a fast local disk to minimize publication delay and I/O waits.
"""