缓存-Redis

一些业务性方面而非技术性方面的问题：

最近有碰到Redis缓存方面的一些问题，因为需求方面沟通说明以及开发流程问题（先完成了查询方面的逻辑又让我加的缓存）使我产生了错误方向的认识结果导致开发过程中出现了一些问题。现总结如下：

社会上的公司一般现实情况下业务增长导致的请求并发量的提升有性能方面的需求时而没有事务性要求时，能纵向扩展就不要过分理想化追求横向扩展，分布式并没有那么美好，各种消息通知处理对众多初级程序员都是危险区。

要区分需求的是缓存还是暂存。缓存设计应该尽可能透明，有或没有对外表现都要一样，拿掉也不影响业务运行，暂存则是确实在跑的业务逻辑，不可被忽略。

1、缓存要求保证事务一致性，暂存不要求，应根据具体业务需求选择开发方向，我烦的错误就是因为一直在考虑事务性方面的问题从而导致开发时束手束脚一直在思考键值结构设计方面的问题而没动手。

2、缓存因为对事务一致性的要求对数据副本管理非常繁琐需要关联架构底层数据库方面的各种失效通知，而暂存不用，我就是因为被告知开发为缓存形式而对同一数据记录在Redis中存储方式的选择而一直纠结。

插入、修改、直接操作数据库，查询因为一般量都比较大所以应该尽量少走数据库。

用Redis常规情况下做暂存时不必须保证数据实时一致性，保证最终一致性即可，MySQL查询性能差，尽量少走到数据库。

Redis数据库是内存数据库快，MySQL数据库是硬盘数据库慢，硬盘数据库无论如何提升性能也不可能在成本可控的情况下达到内存数据库的水平，但我们的很多业务其实根本对数据事务性反面需求并不敏感，开发代码时以业务逻辑数据模型以Redis内存数据库为中心，而不再是以MySQL硬盘数据库为中心，不要再执拗于业务数据的时间精度。