我有一个web应用程序，它有正常的功能、用户设置等，这些都与用户等一起存储在MYSQL中…
应用程序A的特定部分是供用户编辑的数据表。
我想让这个表在多个用户之间实时显示。即多个用户可以打开页面编辑数据，并实时查看其他用户编辑表格所做的更改。
我的想法是在Redis中缓存表的数据，然后在reds中预处理所有操作，比如保持所有客户端的最新状态。
一旦关闭了特定表的所有连接，将数据保存回mysql进行持久化，我知道Redis可以用作持久的NoSQL数据库，但由于RAM有限，并且我的所有其他数据都存储在mysql中，mysql似乎是一个更好的选择。
这是redis的正确用例吗？我的想法正确吗？
这取决于可伸缩性。您将要处理的记录的数量以及用于保存它的结构。
我将讨论使用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列的表占用1GB的内存(只是假设实际内存会少得多)。如果您的redis是10GB集群，那么您只能处理10个这样的表。计算一下你要使用多少rows * column * live tables以及它消耗的内存。
2) Redis对范围内的数据使用压缩http://redis.io/topics/memory-optimization.假设您决定使用hashmap保存表，您有两个选项，对于每列，您可以使用hashmap，或者对于每行，您可以具有hashmap。第二种选择将是最佳选择。因为存储1000(hashmaps->rows)*20(每个hashmap->columns中的记录)将比以其他方式存储占用10倍的内存。同样通过这种方式，如果一个单元格被更改，你可以在20个值以内的hashmap中进行本地化。
3) 将数据加载回您的MYSQL。这种情况多久发生一次？如果您的工作负载很高，那么MYSQL在其他操作中的表现就会变得更差。
4) 在通知更改时，您将如何处理多个客户？你会加载整张表还是更改的部分？装载更改后的零件将是最佳的。在这种情况下，您将在哪里维护已更改的单元格列表？
用这些问题来评估你的系统，你会发现它是否可行。