美好只能封装在记忆的信封之中 ， 喜悦犹如弹指之间飞逝的花瓣 。终究只属于当下和日后的回忆 。往事不能抹去 ， 当下才是新的征程与起点 。
网站最初通常不会存在高并发的情况 ， 使用最简单的LNMP架构即可满足网站中的需求 ， 但随着网站运营时间的累加 ， 用户量的增多 ， 网站在应对大量的用户请求时 。将会出现卡顿、5xx系列错误、页面加载缓慢等问题 。最初网站的流畅运行将随风而逝 ， 眼下就需要程序员解决网站因为并发而造成的一系列问题 。
因为单一使用数据库来保存数据的系统是面向于磁盘 ， 磁盘读/写速度比较慢的问题而存在严重的性能弊端 ， 一瞬间成千上万的请求到来 ， 需要系统在极短的时间内完成 成千上万次的读/写操作 ， 这个时候往往不是数据库能够承受的 ， 极其容易造成数据库系统瘫痪 ， 最终导致服务宕机的严重生产问题 。
文章插图
为了克服上述的问题 ， Web项目通常会引入NoSQL技术 ， 这是一种基于内存的数据库 ， 并且提供一定的持久化功能 。
redis作为一款高性能的Key-Value的键值对缓存数据库 ， 因丰富的数据类型而广泛应用于项目不同的应用场景 。redis可以支持每秒十几万此的读/写操作 ， 并且还支持集群、分布式、主从同步等配置 ， 原则上可以无限扩展 。
但多数情况下 ， 绝大多数开发者只是单纯用Redis做缓存的保留使用 ， 对于其它的数据类型基本都避而不见 ， 但是往往采用Redis其它的数据类型可以代替其应用业务中 需要数据库提供的关系型数据 。例如：投票、排行榜、粉丝统计、消息队列、发布订阅等等 。这些场景的取代可以大幅度的提高网站的响应速度 。
如果只是单纯的接触缓存还无妨 ， 但往往实际场景中用到Redis的地方很多 ， 关键是在于自身如何去接入Redis到网站中 。
会使用 ， 干嘛还要会用redis1、使用最简单 ， 提升最缓慢
任何一门技术想快速入门 ， 莫过于它的使用 ， 因为这个过程中的 ， 你的目的很明确 ， 我就需要知道它大致的操作步骤、使用条件 。入门后在是熟练操作的步骤 ， 总结为自己的经验内容 。
但这样往往有个问题 ， 就是对于项目的业务场景分析不深刻 ， 没有根据业务的情况选择合适的内容 ， 而是万能的套模板式的开发 ， 久而久之就感觉像在做简单的业务开发 ， 没有什么实质性的突破 ， 感觉自己的提升非常的缓慢 。
这就是所谓的认知偏见 ， 在你意识中Redis只可用于缓存 ， 那么任何的业务条件下都是用它按照set 、get的方式来解决实际问题 ， 对于业务场景下面的过程就少了业务场景下结果的分析 。但随着业务快速的发展很快就会出现瓶颈问题 。
例如:今日头条的青云计划中 ， 每天中奖的名单会有100-1000个 ， 同时还有分类的问题 ， 一级、二级、三级 ， 如果按照使用的方式可能就是根据你每个分类+ID值作为key ， value就是固定长度标题+文章内容(也可分开设计key+value) 。虽然设置为缓存了 ， 那如果需要展示的时候怎么好查询呢？
如果设置的时候每个分类对应一条记录对于一个key-->value ， 那你查询就需要规则匹配 ， 这样很容易发生阻塞问题 ， 同时每个分类下面的1 2 3三级的文章 ， 如果在value里面设置对应的标识 ， 取值出来还需要进行修改 。费时又费力 。
那如果把业务拆分成不同的分类、1 2 3级、标题 。我们就可以用有序集合来确定分类名称 ， 对应的标题 ， 等级 ， 用Hash结构做文章内容存储、发布时间、作者、浏览量等 。这样是不是就可以按照业务的组成来选择对应的数据呢？
从而让我们更好的去理解业务 。对于redis的认识也更加深刻 ， 思维上也不在是按照普通的方式 ， 而是根据业务场景选择合适的工具来做
2、好的方法可以节省时间
俗话说“工欲善其事 ， 必先利其器” 。好的数据类型就是我们的工具 ， 如果在开始阶段对业务的分析 ， 决定了选择什么好的数据类型 ， 那么再去做的时候就可业务条件编写即可 。而不是在书写的时候就是那缓存说话 ， 这样你会花费很多的时间去修改对应的数据存储机构到Redis中 。
推荐阅读
- Redis布隆过滤器
- 压缩文件是什么原理？
- 淘宝怎么进分享小站 淘宝分享小站如何开通
- 详解双电源自动切换开关工作原理
- 钓鱼大对决|晚春夜钓正当时！钓鱼老手分享4条爆护秘诀，狂拉大货不含糊！
- 制冷电风扇工作原理
- 行程开关原理及应用
- 漏电保护开关的原理及类型
- 触摸开关原理及特点
- VLAN工作原理之TRUNK：Native Vlan收到不带VLAN的Frame如何处理