这取决于可扩展性。您将要处理的记录数以及您将用于保存它的结构。
我将讨论使用 redis 的优点和缺点。决定权在你。
使用redis的优点:
1) It can handle heavy writes and reads in comparison with MYSQL
2) It has flexible structures (hashmap, sorted set etc) which can
localise your writes instead of blocking the whole table.
3) Read queries will be much faster as it is served from cache.
使用redis的缺点:
1) Maintaining transactions. What happens if both users try to access a
particular cell at a time? Do you have a right data structure in redis to
handle this case?
2) What if the data is huge? It will exceed the memory limit.
3) What happens if there is a outage?
4) If you plan for persistence of redis. Say using RDB or AOF. Will you
handle those 5-10 seconds of downtime?
需要关注的事情:
1)你要处理多少数据?假设 redis 中的 10000 行和 10 列的表需要 1 GB 内存(只是假设实际内存会少得多)。如果你的 redis 是 10GB 集群,那么你只能处理 10 个这样的表。计算一下rows * column * live tables
您要使用的内存数量及其消耗的内存。
2) Redis 对http://redis.io/topics/memory-optimization范围内的数据使用压缩。假设您决定使用 hashmap 保存表,您有两个选择,对于每一列,您可以有一个 hashmap,或者对于每一行,您可以有一个 hashmap。第二种选择将是最佳选择。因为存储 1000 (hashmaps -> rows) * 20 (records in each hash map -> columns) 将比以其他方式存储少 10 倍的内存。同样通过这种方式,如果一个单元格被更改,您可以在 20 个值以内的 hashmap 中进行本地化。
3) 将数据加载回您的 MYSQL。这种情况多久会发生一次?如果您的工作负载很高,那么 MYSQL 开始对其他操作执行更差的操作。
4)您将如何处理通知更改的多个客户?您将加载整个表格还是更改的部分?加载更改的部分将是最佳的。在这种情况下,您将在哪里维护已更改的单元格列表?
用这些问题评估你的系统,你会发现它是否可行。