企业级nosql数据库应用与实战-redis

随着互联网2.0时代的发展，越来越多的公司更加注重用户体验和互动，这些公司的平台上会出现越来越多方便用户操作和选择的新功能，如优惠券发放、抢红包、购物车、热点新闻、购物排行榜等，这些业务的特点是数据更新频繁、数据结构简单、功能模块相对独立、以及访问量巨大，对于这些业务来说，如果使用mysql做数据存储的话，大量的读写请求会造成服务器巨大压力，是否有更轻量的解决，能解决此类问题？

技术说明

NoSQL(NoSQL = Not Only SQL )，意即”不仅仅是SQL”

NoSQL概念在2009年被提了出来

– NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受

– NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列式存储HBASE、图型数据库、xml数据库等

NoSQL产品是传统关系型数据库的功能阉割版本，通过减少用不到或很少用的功能，来大幅度提高产品性能

随着web2.0技术的发展，其促使了物联网和移动互联网迅猛发展。传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展

NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题

传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端,Memcached主要减小数据库的读压力

NoSQL诞生的原因

关系型数据库面临的问题

– 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难；

– 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非 常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重 ；

– 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升；

– 有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储；

数据库访问的新需求

– 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度；

– 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的 流量；

– 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理；

– 庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度 地降低；

– NoSQL数据库仅仅是关系数据库在某些方面（性能、扩展）的一个弥补

– 单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足。

– 一般会把NoSQL和关系数据库进行结合使用，各取所长，各得其所。

– 在某些应用场合，比如一些配置的关系键值映射存储、用户名和密码的存储

– 在某些场景下，用NoSQL完全可以替代关系数据库(如：MySQL)存储。不但具有更高 的性能，而且开发也更加方便

• 优点

– 简单的扩展

典型例子是Cassandra，由于其架构 是类似于经典的P2P，所以能通过轻 松地添加新的节点来扩展这个集群；

– 快速的读写

主要例子有Redis，由于其逻辑简单， 而且纯内存操作，使得其性能非常出 色，单节点每秒可以处理超过10万次 读写操作；

– 低廉的成本

这是大多数分布式数据库共有的特点， 因为主要都是开源软件，没有昂贵的 License成本；

• 不足

– 不提供对SQL的支持

如果不支持SQL这样的工业标准，将会 对用户产生一定的学习和应用迁移成本 ； set m26 linux

– 支持的特性不够丰富

现有产品所提供的功能都比较有限，大 多数NoSQL数据库都不支持事务，也不 像Oracle那样能提供各种附加功能，比 如BI和报表等；

– 现有产品的不够成熟

大多数产品都还处于初创期，和关系型 数据库几十年的完善不可同日而语；

NoSQL总结

• NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足， 在某些方面能极大的节省开发成本和维护成本。

• MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会 给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上， NoSQL关注在功能、性能上。

• 随着移动互联网的发展，以及业务场景的多样化，社交元素的普遍化， Nosql从性能和功能上很好的补充了web2.0时代的原关系型数据的缺点， 目前已经是各大公司必备的技术之一

常见Nosql分类和部分代表



其中redis是其中比较好用的一款NoSQL产品,redis是一个key-value存储系统。和Memcached类似，它支持存储的value 类型相对更多，与memcached一样， 为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了 master-slave(主从)同步。 Redis 是一个高性能的key-value数据库。redis的出现，很大程度补偿了 memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl ，Object-C，Python，Ruby，Erlang等客户端，使用很方便

redis的特性

1、完全居于内存，数据实时的读写内存，定时闪回到文件中。采用单线程,避免了不必要 的上下文切换和竞争条件

2、支持高并发量，官方宣传支持10万级别的并发读写

3、支持持久存储，机器重启后的，重新加载模式，不会掉数据

4、海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除

5、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结 构的存储。

6、灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；

7、虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘；

8、Redis支持数据的备份，即master-slave模式的数据备份；

redis功能模块说明

各功能模块说明如下：

File Event: 处理文件事件，接受它们发来的命令请求（读事件），并将命令的执行结果返 回给客户端（写事件）)

Time Event: 时间事件(更新统计信息，清理过期数据，附属节点同步，定期持久化等)

AOF: 命令日志的数据持久化

RDB：实际的数据持久化，根据字符来查找相应命令的实现函数。

Share Objects（对象共享）： 主要存储常见的值：a.各种命令常见的返回值；b. 小于 redis.h/REDIS_SHARED_INTEGERS (默认1000)的所有整数。通过预分配的一些常见的值对象，并在多个数据结构之间共享对象，程序避免了重复分配的麻烦。也就是说 ，这些常见的值在内存中只有一份。

Databases： Redis数据库是真正存储数据的地方。当然，数据库本身也是存储在内存中的

redis安装方式

redis安装常用两种方式，yum安装和源码包安装

yum 安装：通常是在线安装，好处是安装方式简单，不易出错；常 用的安装yum源为epel

源码包安装：是先将 redis 的源码下载下来，在自己的系统里编译生 成可执行文件，然后执行，好处是因为是在自己的系统上编译的，更 符合自己系统的性能，也就是说在自己的系统上执行 redis 服务性能 效率更好

区别：路径和启动方式不同，支持的模块也不同

实验：redis主从复制

第一步：准备好四台机器一台主，三台从

192.168.159.129 redis-master

192.168.159.77 redis-slave

192.168.159.79 redis-slave

192.168.159.120 redis-slave

第二步：在四台节点上

安装redis,在4台节点上配置好基本配置

yum install redis

cp /etc/redis.conf{,.back}

vim redis.conf

daemonize yes

bind 0.0.0.0 #改为各个节点的IP，最好改为0.0.0.0，不要127.0.0.1

第三步：配置三台从节点在配置文件中加入以下一句配置

slaveof 192.168.159.129 6379 #主节点地址

第四步：redis主从复制测试

在主节点上用redis-cli info查看会看到其中如下一段信息

Replication

role:master

connected_slaves:3

slave0:ip=192.168.159.79,port=6379,state=online,offset=3479,lag=0

slave1:ip=192.168.159.120,port=6379,state=online,offset=3479,lag=1

slave2:ip=192.168.159.77,port=6379,state=online,offset=3479,lag=1

在3台从节点上用redis-cli info 查看

Replication

role:slave

master_host:192.168.159.129



在三台从节点上均做如下测试



以上基本的redis主从复制已经实现，下面做一些redis的高级配置

五、高级配置

redis可以通过sentinel机制实现主节点故障时自动切换功能，也即故障转移，Sentinel是Redis的高可用性（HA）解决方案，Redis提供的sentinel（哨兵）机制，通过 sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送 通知。

实际配置

vim /etc/redis-sentinel.conf

sentinel monitor mymaster 192.168.159.129 6379 1 其中129是主redis节点ip地址，1是设置的哨兵数，也就是至少一个哨兵认为主Redis节点故障就判定主redis故障

实际生产中哨兵最少设置3个，如果设置一个哨兵如果它坏掉了就没有高可用了，设置2个哨兵的话容易出现脑裂，所以生产中的哨兵设置都是奇数位且最少设置3个

systemctl start redis-sentinel

现在来模拟主redis节点故障，在redis-master节点上直接杀死redis进程

来查看一下redis日志tail -f /var/log/redis/sentinel.log

发现redis主节点切换了



通过以上配置可以看出redis的sentinel机制可以实现自动故障迁移（Automatic failover）， 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将 失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端 试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器