Redis探索

简介

Redis是使用ANSI C编写,基于内存亦可持久化的数据库。因为Redis是基于内存存储的,所以性能非常的优越。

然而还是有些缺点,比如Redis单线程的设计无法利用好CPU资源,尤其在现今服务器动不动就24核32核的情况下。
基于内存Redis在内存使用量巨大时,管理和维护十分的困难和低效。
等等。

*上面的问题可以使用单机多示例Redis然后采用客户端分片的模式解决。

问题

思考:数据库什么情况下要分库?

分库分表就是把原本存储在一个库的数据分块存储到多个库上,把原本存储于一个表的数据分块存储到多个表上。

至于为什么要这么做,是因为数据库中的数据量不一定是可控的,那就有可能随着时间和业务的发展,库中的表会越来越多,表中的数据量也会越来越大,这样数据操作的成本就会增加;同时不进行分库分表的话即无法分布式部署,而一台服务器的资源(CPU、磁盘、内存、IO等)是有限的,最终硬件上也会达到瓶颈。

思考:存储RAID阵列是是啥?提高的性能包括写性能么,为什么一份数据存多份写性能也可以提高呢?

RAID含义是,由独立磁盘构成的具有冗余能力的阵列。

ME.关于写性能,是不是我可以并行的往不同的磁盘里面写,所有写的时候能提高性能。
OT.说的是读的时候先读有热点数据的缓存,否则读阵列;写的时候是客户端写缓存,阵列自己处理写磁盘。

*目前看法院很需要部署RAID。性能方面其次,主要是能保证数据的安全性稳定性。跟同事讨论了一下,感觉法院又没必要搞,当然搞肯定不会错的。

思考:Redis和传统数据库的区别,各自的优缺点?

最大的区别即Redis数据采用内存存储的方式。这样带来的结果是高性能,而缺点也很明显,内存的成本可是比磁盘的成大大太多。所以我们尽可能的只是把热点数据存在Redis里面。当然如果可以壕的不考虑成本,那就可以看看下面的一些问题。

比如新老系统的迁移,原来数据库场景下的没有问题的地方,确定换成Redis不会成为难点?
为此会不会大动甚至更改架构(夸张了,毕竟有分层,但是如果真的架构有问题的话真的玩完)?
等等。

然后因为是新兴技术还有还有一些地方需要考量,这并不算缺点,如果架构合理应该是可以避免的。需要注意的场景如下:

1、Redis-RDB半持久化模式下,非实时,如果一旦断电,丢失一些数据,程序能不能接受、兼容?
2、Redis主要是Key的查询,对于复杂的数据结构,需要其他sql是不是更爽?需要其他关联查询?
3、Redis吃的是纯内存,跟磁盘相比,成本也要计算在内?
4、是否需要支持像银行存取款级别的事务?
5、数据总有“冷”、“热”之分,10亿的冷数据都放Redis显然浪费资源。

ME.分析东西要有一定的套路,要抓住重点,比如分析这个思考题,其实需要梳理清楚我们使用数据层的每个流程,我们现在是怎么实现的,我们如果用Redis怎么实现等等。一开始确实不太容易想的比较全面,但是要让自己去这么做。

思考:Redis主从模型为解决什么场景的?(新事物的产生真的是有其原因的,凭空出现真的很难,所以说我这个问题问的很蠢,会问这种问题的人也比较蠢,问问题应该是拿出场景来,看我们怎么能解决这个问题。而不是猜测他应该去解决什么东西。当然不能一概而论,毕竟这段话也是根据这个场景来的。呵呵。。。。。)

先说一下主从是个什么东西,就是我们会启动二个及以上的Redis服务然后把他们包装成一个对外的Redis服务,别人用你的时候就知道你是个Redis就好啦,获取连接从你这儿获取数据或者存放数据,而并不需要关心拿到的是哪个Redis服务的连接。而我们自己需要对这些服务进行区分(当然说是我们去干,其实我们也只是做一些配置),配置好实现后,主服务会包揽写操作,而从服务主要是供读取数据的,并同步来自主服务的数据。

回归正题,这样能带来的好处如下:
1、避免Redis单点故障
2、构建读写分离架构,满足读多写少的应用场景

主从同步原理:
1、当从库和主库建立MS关系后,会向主数据库发送SYNC命令
2、主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来(Reids2.8.18版本中实现了磁盘复制,直接通过网络把快照发送给从者。)
3、当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis
4、从Redis接收到后,会载入快照文件并且执行收到的缓存的命令
5、之后,主Redis每当接收到写命令时就会将命令发送从Redis,从而保证数据的一致

引用

Redis探索

Redis 可以用来做数据库吗?

RAID百科词条

Redis学习笔记~Redis主从服务器,读写分离

jinhy wechat
微信扫一扫,欢迎关注我的订阅号~
坚持原创,您的支持将鼓励我继续创作,去追寻星空~