实时股票应用系统的关键设计

Question

我正在尝试建立一个实时股票应用程序。每秒钟一次，，我可以从web服务获得一些数据，如下所示：

{“金额”：“20”，“日期”：1386832664，“价格”：“183.8”，"tid":5354831，“类型”：“出售”}，{“数量”：“22”，“日期”：1386832664，“价格”：“183.61”，"tid":5354833，“类型”：“购买”}

tid是股票买卖的票证；日期是从1970.1.1开始的第二个日期；价格/金额是以什么价格和多少股票交易的。

退休

我的要求是实时显示用户每分钟/5分钟/小时/天的最高/最低价格；实时显示用户每分钟/5分钟/小时/天的金额之和。

问题

我的问题是如何将数据存储到redis，这样我就可以轻松、快速地从DB获得不同时期的最高/最低交易。

我的设计如下：

[date]:[tid]:amount
[date]:[tid]:price
[date]:[tid]:type

我是新来的。如果设计是--这意味着我需要使用排序集--会有任何性能问题吗？或者有其他的方法来获得不同时期的最高/最低价格。

期待您的建议和设计。

Answer 1

我的建议是存储您感兴趣的所有时间间隔的最小/最大/总计，并用每个到达的数据点更新当前的数据。为了避免在读取以前的数据以进行比较时的网络延迟，您可以使用Lua脚本在Redis服务器中完全完成该任务。

每个数据点有一个键(更糟的是，每个数据点字段)将消耗过多的内存。为了获得最好的结果，您应该将其分组为小列表/散列(参见http://redis.io/topics/memory-optimization)。Redis只允许在其数据结构中进行一层嵌套:如果数据有多个字段，并且希望每个键存储多个项，则需要自己对其进行编码。幸运的是，标准Redis环境包括味精包支持，这是一种非常有效的类似于二进制JSON的格式。示例中用msgpack "as“编码的JSON条目将有52-53字节长。我建议按时间分组，这样每个键就有100到1000个条目。假设一分钟间隔符合这一要求.那麽键控计划就会是这样：

YYmmddHHMMSS -在给定分钟内从tid到msgpack编码的数据点的散列。5m:YYmmddHHMM，1h:YYmmddHH，1d:YYmmdd -窗口数据散列，其中包含min、max、sum字段.

让我们看一个示例Lua脚本，它将接受一个数据点，并根据需要更新所有键。由于Redis脚本的工作方式，我们需要显式传递脚本将访问的所有键的名称，即实时数据和所有三个窗口键。Redis Lua也有可用的JSON解析库，因此为了简单起见，让我们假设我们只是传递它JSON字典。这意味着我们必须对数据进行两次解析:在应用程序端和在Redis端，但其性能影响尚不清楚。

local function update_window(winkey, price, amount)
    local windata = redis.call('HGETALL', winkey)
    if price > tonumber(windata.max or 0) then
        redis.call('HSET', winkey, 'max', price)
    end
    if price < tonumber(windata.min or 1e12) then
        redis.call('HSET', winkey, 'min', price)
    end
    redis.call('HSET', winkey, 'sum', (windata.sum or 0) + amount)
end

local currkey, fiveminkey, hourkey, daykey = unpack(KEYS)
local data = cjson.decode(ARGV[1])
local packed = cmsgpack.pack(data)
local tid = data.tid
redis.call('HSET', currkey, tid, packed)
local price = tonumber(data.price)
local amount = tonumber(data.amount)
update_window(fiveminkey, price, amount)
update_window(hourkey, price, amount)
update_window(daykey, price, amount)

这种设置可以每秒进行数千次更新，对内存不太需要，并且可以立即检索窗口数据。

更新:在内存部分，如果您想要存储更多的几百万，那么每点50-60个字节仍然是很多的。使用这种数据，我认为您可以使用自定义二进制格式、增量编码以及随后使用斯巴比之类的块压缩来获得每点2-3字节的数据。这取决于您的需求，是否值得这样做。