Redis 开天篇

本文主要是介绍Redis 开天篇，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

-M- 程序源自于生活，又作用于生活~

本章主题：redis是什么？redis好在哪? 为何不用其他技术? 如何学习redis?
本章答案：底部解答。

redis是什么？

redis到底是个啥东西呢？ 你可能听到这个问题 已经有一堆话抛到嘴边了~（nosql#非关系型数据库￥还有不知道这个的人吗？高效数据库呗/缓存’会用就行管它是啥呢；等等）

hold on 抛出这个问题的想法是 从生活的角度 你是否能够说的出来？

技术发展

架构的发展过程是从： 单体架构（简单一体机-MVC-前后端分离）进化至 SOA 服务 分布式架构

生活阐述

以前有电脑的人是少数的，硬件设备也是一般的，看个新闻就满足了。现在呢，电脑家家有，手机人人有，微博，抖音，京东，淘宝，这边投个票了，那边买个东西了，内容越来越多，而且 The important point is 要快，你这个APP要是加载个页面2s以上那基本凉了，谁用，你用吗，反正我不用。
道理都懂，要丰富内容，要响应迅速，随着用户群体增多，请求变多，单体架构扛不住这么大的流量，数据库硬盘可能大量读写就嗝屁死机了，于是乎，为了解决大数据并发性能问题架构进行升级，那技术也得更新。

生活故事 看故事就得耐心看完哦v

不难有人会想到，一台电脑搞不定，多搞一些服务器不就好了，就像窗口买车票，人越多开的售票窗口越多不就能够满足 人流量大而且快速响应买票的需求了呗，确实没毛病，也正是分布式架构的思想，但是注意！！！一口吃不成胖子（除非天生），像北上广这样的城市确实人流量大，几十个售票窗口，但是一个18线小城市是不可能有几十个售票窗口。流量是一点点增加的，架构也是一点点完善的，技术也是在不断的进化改造升级的。在流量增多初期是不会分布式这样做的，增加窗口不得花钱啊，窗口小姐姐小哥哥上班不得给工资的，用技术填补能不花钱的地方尽量不花，不然要程序员干什么。用一个故事来感受一波~

背景：火车并不发达时期买火车票的一个列子
场景：1. 人不多 2. 人有点多了 3. 人特别多
角色：贵族 贫民 窗口小姐姐/小哥哥 仓库大叔 站长 上级领导 小伙子

在场景1的时候，都是一些贵族买得起火车票，这个时候只需要一个窗口一个小姐姐售票，一个大叔管着所有票即可，买票也不用拥挤。后来国家发展的越来越好，越来越多的人买得起车票，到了场景2，贵族发现，买个车票还需要和一帮贫民一起围着窗口去拥挤去买票，很有失风度，于是乎找来站长，跟站长说，要不我给你钱，给我开个后门让我买票方便一点，站长一听，此注意甚好（可以捞钱），于是从 管票大叔那里 拿了几十张票放自己口袋里面，贵族直接从站长手里拿票，不用去窗口买了，甚至还能包邮到家。
OK，到这 你会明白一个道理，有钱真好，不对，是从站长手里拿票，比去窗口买票，窗口去仓库拿票这一环节 来的更容易些。 而这一环节 在软件概念上 我称之为 缓存 ；

而此时贫民还在为买票的窗口发愁，你推我嚷的叭叭叭吧，如果要是身子瘦小还真得花不少时间，这样一来，来的早的人发现并不得劲，就开始哭天喊娘的给站长哭穷，站长一看，是时候表演真正的技术了，于是第一步又开设了一个卖票窗口，第二步 设立了排队机制 先来后到的排好队 依次领取 号码牌 第三步，设置等待区 叫号的去 买票 没叫到的在等待区 等待，并保证了等待区限制人数50人。其他人在候补区等，这样一来 甚好，有条不紊，1号去1号窗口 2号去2号窗口 等1号完了叫3号；
OK， 到这 你会明白一个道理，站长有点东西，不对，是排队之后的效率变高了（消息队列），俩个窗口效率变高了（异步），主动问窗口的模式变成窗口呼叫效率变高了（非阻塞IO-IO多路复用），等待区域限制人数（流量削峰），买票大众不在彼此争执，买票的买，等待的等，候补的候（解耦）
这样的工作效率传到了上级领导那里，上级领导 Mr.尚决定来视察一番，并且好奇问站长，一个月卖了多少张票，站长慌得一比，这哪能知道啊，站长去问窗口1小姐姐和2小哥哥，但是并不晓得，没办法站长于是去问仓库大叔卖了多少啊，仓库大叔说 每卖出一张就划正字，然后数了数告诉了站长。受到了上级领导的表扬并进行了宣传；
OK， 到这 你会明白一个道理 大叔画正字也太帅了，不对，是每卖一张记录的信息也太帅了，这样统计的时候不是手到擒来。（原子操作）

由于受到了上级的宣扬，导致在这里买车票的热度一度变 沸，那真是红旗招展，人山人海，而且贵族买票的人也越多了，站长也吃不消了，于是乎聪明的站长又开始支招了， 站长 开设了多个服务区，贵族服务区，贫民服务区，然后每个服务区有自己的多个售票窗口，多个等待区与候补区，而之前跟贵族交易的经验也用到了正事上面，找来了一批非常有活力的小伙子，这群小伙子负责不同的服务区，然后在 仓库大叔 那里 提前拿一些票出来放到 窗口小姐姐/小哥哥这里，感觉票快用完了，就再去仓库大叔那里去拿；
OK， 到这 你会明白一个道理 啥也不是 不就是 比葫芦画瓢，原来就是这，现在还是这 就是 一套一套得 复制了几个服务区罢了，而这也正是SOA服务分布式的道理，分身术

小结

一：redis是什么？
答：是在时代发展中，为了解决大数据并发请求响应慢的方案中诞生出的一门高可用高性能数据库技术，一种key-value非关系型数据库。起初被广泛认知用于缓存；但作用不止于此；
二：redis好在哪？为何高可用高性能？
(0) 非关系型数据库 维护性高 开源 生态环境好
(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)

(2) 支持丰富数据类型，支持string，list，set，sorted set，hash，geo,hyperloglog,bitmap,stream

(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行

(4) 丰富的特性：可用于缓存，消息队列，按key设置过期时间，过期后将会自动删除
(5) 网络请求模块单线程执行，并不是完全单线程，别的模块多线程
(6) IO多路复用

三：如何学习redis？
答：学习redis，你要看你学的程度是什么，会用的话一点都不难，懂原理的话那就要下功夫了，我也是小白~
学就是要学redis的优点，为什么性能好，为什么就快了，学原理。学思想；
我的后续章节就从 基础知识数据结构等-消息队列-分布式-主从-哨兵-持久化等等来进入学习，我准备在7月底讲redis系列章节完善~

四：为什么不用其他技术？
答：缓存作用方面：Redis与Memcached的区别
等等一些方面，后续会做一个章节讲。

五：缺点
答：后续章节讲，一开始就记得人的好，人的好都懂了，在去了解缺点，完善！缓存击穿雪崩，持久化问题，等等

使用场景

这篇关于Redis 开天篇的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！