这种业务情况用不用另外捣鼓个缓存？

[小灰狼]

系统功能大概是：
一个物联网系统。终端通过物联网卡与服务器通信。服务器保存有每个终端设备的业务状态，状态更新不会非常频繁，终端工作时，状态更新周期为5秒，空闲时状态更新为1分钟。另外会有一个 Java Web 服务器会比较频繁地读取这些设备的最新状态。终端设备的数量一般不会超过10W个。
另外，数据库会有几个数据量会比较大的表，用于存储终端设备的业务历史状态。这个表的数据量可能会比较大，如果有业务功能对这个表进行查询，会拉低其它数据库业务性能。

以前我们用 redis 存储设备的最新状态，理由有：
1、专用缓存服务器，速度快
2、redis 支持本地持久化，系统重启时还能保持状态

但现在我感觉这个 redis 有点多余。因为10W的数据量对 MySQL来说不算大，再加上最新的状态数据，如果另建一个表存储的话，也是10W级，也不算大。应用程序直接从数据库中查询的话，应该不存在什么性能瓶颈吧？只要我内存足够大（其实也不需要非常大），MySQL 自身的缓存机制就能应付！

[小灰狼]

居然没人？
自己顶一下先！

[二月十六]

看实际需要，如果不加缓存，能满足需求那就不加，如果确实觉得慢不能接受，那就加，缓存本来就是提高性能的手段。

[小灰狼]

引用 2 楼 sinat_28984567 的回复:

看实际需要，如果不加缓存，能满足需求那就不加，如果确实觉得慢不能接受，那就加，缓存本来就是提高性能的手段。

缓存确实是为了提高性能而引入的
但是对我的应用来说，数据量不算非常大，一般不超过10万个终端，再加上每个终端会有一个最新的实时状态。如果每个终端的所有数据占用2k，则这些数据量总共才不过 2k * 100000 < 200M。
如果 MySQL 服务器内存能够达到8G，而这些数据经常被访问到的话，我想 MySQL 的缓存机制应该会把数据缓存在内存中，这和直接使用 redis 没什么太大区别了。

[小灰狼]

另外，加一个 redis 缓存服务器，其实就把给数据整了一份副本，应用程序必须要创建一种机制在 mysql、redis 之间进行数据同步。以及业务方面的事务处理也会变得复杂。

[小灰狼]

没别的意见了吗？
自己顶一下