redis分布式和mysql分布式/集群

时间：2020-04-18 09:38:46 阅读：230 评论：0 收藏：0 [点我收藏+]

分布式和集群

目前的项目很少会采用单机架构了，一是因为单机性能有限，二是因为单机服务一旦故障整个系统就无法继续提供服务了。所以目前集群和分布式的架构使用得很广泛，主要就是为了解决上述两个问题，一个性能问题，一个故障问题，通过分布式架构解决性能（高并发）问题，通过集群架构解决故障服务（高可用）问题。

分布式架构

分布式：一个业务分拆多个子业务，部署在不同的服务器上

网上很多文章把分布式架构说得很复杂，但都没有切中关键，其实理解起来很简单，所有的计算机系统都是为业务服务的，将同一个业务拆分成多个子业务，各个子业务部署在不同的服务器上，这就是分布式架构，通过将业务拆细，为不同的子业务配置不同性能的服务器，提高整个系统的性能。我个人认为目前很火的微服务概念其实本质上就是分布式。

按照类型大致可以分为两种：分布式计算和分布式存储。

分布式计算很好理解，就是将大量计算任务分配到多个计算单元上以提高总计算性能。例如暴力破解某个密码需要遍历某个字符组合10万次，假设一台计算机需要10分钟，那么10台计算机同时遍历，每台遍历1万次，最后将结果汇总，那么就只需要1分钟。这10台计算机组合起来就是一个分布式计算系统，这里的业务就是计算。

同理，分布式储存也很好理解，就是将大量数据分配到多个储存单元上以提高总存储量。例如100ZB的数据一个储存单元放不下，那就拆成100份，每个储存单元存1份，那么这100个存储单元组合起来就是一个分布式储存系统，这里的业务就是存储。目前主流的关系型数据库都有比较成熟的分布式存储方案，如 MySQL 的 MySQL Fabric、MyCat 等，Oracle Database 有Oracle Sharding 等。Redis 作为流行的非关系型数据库，由于是内存数据库，理论上一般不会在 Redis 中存放太多的数据，但是在某些特殊情况下还是会有储存空间不够的情况，或者需要预防储存空间不够的情况发生，这个时候就需要 Redis 分布式架构了。

例如某集团下有很多的子公司，每个子公司都有多套 IT 系统，其中很多 IT 系统都是需要使用 Redis 的，集团为了统一管理，搭建了一套中央 Redis 系统，要求所有子公司下的 IT 系统统一使用集团的中央 Redis 库，这个时候即使当前储存容量够用，但是为了应对后期发展就必须使用到分布式储存，因为分布式架构理论上都支持无限水平拓展。

集群架构

集群：同一个业务，部署在多个服务器上

集群同样也非常好理解，就是在多个服务器上部署同一个业务，这样可以起到两个作用：

分散每台服务器的压力
任意一台或者几台服务器宕机也不会影响整个系统

Redis单节点部署

方法如下：

# 下载 Redis 二进制安装包：
wget http://download.redis.io/releases/redis-5.0.4.tar.gz
# 解压二进制包
tar –zxvf redis-5.0.4.tar.gz
# 进入解压文件夹并编译二进制文件
cd redis-5.0.4
make
# 安装
cd src
make test
make install

启动和检查

# 进入到 redis 的安装目录，编辑 redis.conf
vim /usr/redis/redis-5.0.4/redis.conf
# 将 daemonize no 修改成 daemonize yes （使 redis 服务可以在后台运行）

# 在指定配置下运行redis服务
/usr/local/bin/redis-server /usr/redis/redis-5.0.4/redis.conf 
# 查看redis运行情况
ps -ef | grep redis

# 输出
app   21794   1  0 Jan28 ?  03:31:25 ./redis-server *:6379

redis高可用

Redis Sentinel 是 Redis 官方推荐的高可用性(HA)解决方案，这是生产环境中最实用也是最常用的方案。

这里涉及到另一个概念：master-slaver（主从模式）。很好理解，就是常用的主备模式，例如 nginx 的主备模式。一个主 redis 节点可以配置多个从节点，当主节点挂掉时，从节点自动顶上代替主节点，这样就可以有效的避免一个节点挂掉导致整个系统挂掉的问题，实现 redis 服务的高可用。

但是这个方案需要解决两个基本问题：

如何提前判断各个节点（尤其是主节点）的运行健康状况？
当主节点宕机的时候如何从多个从节点中选出一个作为新的主节点并实现自动切换？

这时 Redis Sentinel 应运而生，它主要有以下三个特点：

监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）：当被监控的某个 Redis 服务器出现问题时，Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，Sentinel 会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

Mysql分布式集群

1. 为什么使用分布式数据库

随着计算机和信息技术的迅猛发展和普及，行业应用系统的规模迅速扩大，行业应用所产生的数据量量呈爆炸式增长，动辄达到数百TB甚至数百PB规模，已远远超出现有的传统计算技术和信息系统的处理能力，而集中式数据库面对大规模数据处理逐渐表现出其局限性，因此，人们希望寻找一种能快速处理数据和及时响应用户访问的方法，也希望对数据进行集中分析、管理和维护。这已成为现实世界的迫切需求。

分布式数据库是在集中式数据库的基础上发展起来的，是计算机技术和网络技术结合的产物。分布式数据库是指数据在物理上分布而逻辑上集中管理的数据库系统。物理上分布指的是分布式数据库的数据分布在物理位置不同并由网络连接的节点或站点上；逻辑上集中是指各数据库之间在逻辑上是一个整体，并由统一的数据库管理系统管理。不同的节点分布可以跨不同的机房、城市甚至国家。

分布式数据库的主要特点如下：

透明性：用户不必关心数据的逻辑分区和物理位置的分布细节，也不必关心重复副本（冗余数据）的一致性问题，同时不必关心在局部场地上数据库支持哪种数据模型。对于系统开发工程师而言，当数据从一个场地移到另一个场地时不必改写应用程序，使用起来如同一个集中式数据库。
数据冗余性：分布式数据库通过冗余实现系统的可靠性、可用性，并改善其性能。多个节点存储数据副本，当某一节点的数据遭到破坏时，冗余的副本可保证数据的完整性；当工作的节点受损害时，可通过心跳等机制进行切换，系统整体不被破坏。还可以通过热点数据的就近分析原则减少网络通信的消耗，加快访问速度，改善性能。
易于扩展性：在分布式数据库中能够方便地通过水平扩展提高系统的整体性能，也能通过垂直扩展来提供性能，扩展并不需要修改系统程序。
自治性：各节点上的数据由本地的DBMS管理，具有自动处理能力，完成本场地的应用或局部应用。

2. MySQL Cluster原理

MySQL 群集是 MySQL 适合于分布式计算环境的高可用、高冗余版本。它采用了 NDB Cluster 存储引擎，允许在 1 个群集中运行多个 MySQL 服务器。在 MySQL 5.0 及以上的二进制版本中，以及与最新的 Linux 版本兼容的 RPM 包中提供了该存储引擎。

MySQL 群集是一种技术，该技术允许在无共享的系统中部署“内存中”和“磁盘中”数据库的 Cluster 。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。MySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括 MySQL 服务器，NDB Cluster 的数据节点，管理服务器，以及（可能存在的）专门的数据访问程序。

管理服务器(MGM节点)负责管理 Cluster 配置文件和 Cluster 日志。Cluster 中的每个节点从管理服务器检索配置数据。

当数据节点内出现新的事件时，节点将关于这类事件的信息传输到管理服务器，然后，将这类信息写入 Cluster 日志。

目前能够运行 MySQL Cluster 的操作系统有 Linux、Mac OS X 和 Solaris，最新的版本已经支持 Windows 操作系统。

MySQL 群集的数据节点之间的通信是不加密的，并且需要高速的带宽，所以建议把群集建立在一个高速局域网内，不建议跨网段、跨公网的部署这种系统体系。

技术图片