处理并发问题的重点不在于你的设计是怎样的
而在于你要评估你的并发,并在并发范围内处理。
你预估你的并发是多少,然后测试r+m是否支持。
还有要纠正你下,缓存的目的是为了应对普通对象数据库的读写限制,依托与nosql的优势进行高速读写。
redis本身也有并发瓶颈。
所以你要把读写和并发区分开来处理。
1:峰值并发,最小并发,最高并发,读写
你的峰值并发应该在你设计的最小并发和最高并发之间寻求平衡
缓存更多处理读写问题,并发并不是主要目的。
分布处理并发
缓存处理读写
50个并发只有50次读写,优化mysql就够了。
50个并发10万次读写,就必须用nosql缓存
200以上并发200读写,分库分表或者读写分离
200以上并发百万级读写,就需要redis或者其他nosql进行分布式来提高实时性能。
还有考虑只读的特殊性
以上的50和200只是距离,具体单一服务器单一部署的支撑上限,也要看压力测试的结果
mysql高手可以做到1500并发的我见过,200并发就超时的redis我也见过
2:维护性要考虑不同系统进行部署实施运维的难易程度
3:根据具体业务
只读业务是不是可以用mysql分布做只读库和只读表,进行读写分离+库分布
拆库拆表不能搞定再考虑上多级缓存
任何设计,你外面套一层,就多一倍的维护成本,缓存不是万金油
链接:https://www.zhihu.com/question/53819414/answer/136758516