一、如何解决一致性问题
一个总的原则
一旦数据库更新了，就把原来的缓存失效掉
- 有时候要做到这一点是很困难的，似乎听起来很可笑，但是当系统规模达到一定程度的时候，这个问题就会凸显。在一个大的团队中，每个开发都在系统里面提交自己的代码，很可能某段代码修改了数据库，但是忘了清缓存，造成生产环境发生故障。对于这种问题，主要得靠代码review来解决。
- 另外，在故障发生的时候，我们不能束手无策，换句话说，系统内部也要有可以直接触发的清理缓存的”接口“，这个接口可以是一个特殊的url，或者一个只有内部才能访问的控制台等。
关于折衷的问题
假设有一个数据，它更新频繁，访问量很高，我们将其缓存，但是由于更新频繁，所以可能频繁触发清缓存操作，这样缓存实际上就成了摆设。如果业务允许，我们不需要每次都清缓存，简而言之，就是允许系统存在一小段时间的数据显示不一致的情况。这是一个比较折衷的方法，对用户体验而言，也无大碍。
更加高级的缓存
页面静态化
以上说的缓存，都是数据缓存，还有一种更加高级的缓存，即把动态页面（如JSP）进行静态化处理，这个比数据缓存复杂的多。目前有一些开源的框架可以支持，比如varnish，性能很高，当然学习成本也很高。关于varnish的使用，本文就不赘述了，有兴趣的可以自行去其官方网站查阅。
二、如何解决实时性问题
- 首先"确保从缓存读取的数据是最新的”这个想法就有点走入误区，既然是缓存，那么必然对数据的实时性有一定的容忍度，可以是5分钟，也可以是5小时，取决于不同的业务场景。
- 然后，一定要求是实时性的数据，就不应该从缓存里读取，比如 库存和价格，应该直接从数据库读取实时数据
- 也可以选择缓存较短时间，甚至做到一个网站里不同页面的价格读取采用不同的方案，以“京东商城”为例，京东的商品列表页面的价格是有5分钟的缓存时间的，而它的商品详情页的价格却是实时的