【HBZ分享】高并发下如何设计缓存来提升系统性能？
普通模式
- 普通模式即前段调用后端接口，然后后端先查缓存， 查不到的情况下再查数据库，然后把数据库中的内容放到缓存中。
- 瓶颈：瓶颈在于tomcat的性能，一般并发可以，面临海量并发冲击，tomcat就显得心有余而力不足了。
主角1： Nginx + Lua + Redis模式
- 通过Lua脚本二次开发Nginx，使得nginx可以直连redis获取数据，nginx的单节点性能可达到10W / s 的查询。
- lua脚本可以直接连redis，同时也可以直接连mysql，当redis没有数据的时候，即可以通过后端查mysql，也可以直连mysql查询，然后再放入到redis中，具体就看怎么设计了
- 缺点：做redis和mysql数据同步时，还需要自行写逻辑，以及还要维护不同应用程序多个key的情况，并且一致性问题也会有， 增加开发复杂度
主角2： Nginx + Lua + Redis + Cancel模式
- 这个比主角1多了个cancel，这个cancel会读取mysql server的binlog日志，然后发送到Kafka或者Rabbitmq中， 在使用java进行监听Kafka，然后把kafka的内容进行解析，更新到redis缓存即可。
- 然后nginx依然结合lua脚本，直接连radis即可，并且无需格外考虑Redis如果不存在是否要从数据库查询，因为只要数据库数据有变动，cancel就会监听到，然后把变动的数据发送到kafka，后端监听kafka会自动把数据更新到缓存中。
- 这种方案的数据同步全程无需写多余的逻辑代码，只需要监听cancel发送到kafka中的数据即可，然后做一个更新，极大地减少开发复杂度，并且也更能够缩短数据不一致性的时间间隔。
- 缺点：链路更加复杂，要确保Cancel的可用性，适合超高并发的大型项目下使用。并且依然会存在一部分数据不一致性问题。
有关数据一致性的问题，是否有解决方案能够达到完全一致性？
答案： 只要使用了缓存，就必不可能达到强一致性，没有任何方案能做到，缓存和DB之前永远存在着一层网络交互，所以就永远不可能实现强一致性。