大数据分布式数据库

1、Redis是什么？

Redis是可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库（NoSQL非关系型数据库），并提供多种语言的 API。Redis 与其他 key - value 缓存产品有以下三个特点：

1、Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
2、Redis不仅仅支持简单的key-value类型的数据，同时还提供String，list，set，zset，hash等数据结构的存储。
3、Redis支持数据的备份，即master-slave模式的数据备份。

1.1、Redis都有哪些使用场景？

1、热点数据的缓存
由于redis访问速度块、支持的数据类型比较丰富，所以redis很适合用来存储热点数据，另外结合Redis Expire 命令我们可以设置过期时间然后再进行缓存更新操作，这个功能最为常见，我们几乎所有的项目都有所运用。
2、排行榜相关问题
关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet进行热点数据的排序。
如要展示各个部门的点赞排行榜， 所以我针对每个部门做了一个SortedSet，然后以用户的openid作为上面的username，以用户的点赞数作为上面的score，然后针对每个用户做一个hash，通过zrangebyscore可以得到以分数倒序排列的序列，zrank可以得到一个部门在该排行榜的位置。
3、计数器
如文章的阅读量、微博点赞数、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。我们可以先写入Redis再定时同步到数据库，Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。
计数功能应该是最适合 Redis 的使用场景之一了，因为它高频率读写的特征可以完全发挥 Redis 作为内存数据库的高效。

1.2、Redis有哪些功能？

1、基于本机内存的缓存
当调用api访问数据库时，假如此过程需要2秒，如果每次请求都要访问数据库，那将对服务器造成巨大的压力，如果将此sql的查询结果存到Redis中，再次请求时，直接从Redis中取得，而不是访问数据库，效率将得到巨大的提升，Redis可以定时去更新数据（比如1分钟）。
2、持久化
如果电脑重启，写入内存的数据是不是就失效了呢，这时Redis还提供了持久化的功能。
3、哨兵（Sentinel）和复制
哨兵模式，如果主机Down掉，哨兵会从从机中选择一台作为主机，并将它设置为其他从机的主机，而且如果原来的主机再次启动的话也会成为从机。Sentinel可以管理多个Redis服务器，它提供了监控、提醒以及自动的故障转移功能；
复制则是让Redis服务器可以配备备份的服务器；
Redis也是通过这两个功能保证Redis的高可用；
4、集群（Cluster）
单台服务器资源总是有上限的，CPU和IO资源可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上，但是内存资源怎么办，主从模式只是数据的备份，并不能扩充内存；

现在我们可以横向扩展，让每台服务器只负责一部分任务，然后将这些服务器构成一个整体，对外界来说，这一组服务器就像是集群一样。

1.3、Redis为什么是单线程的？

1、代码更清晰，处理逻辑更简单；
2、不用考虑各种锁的问题，不存在加锁和释放锁的操作，没有因为可能出现死锁而导致的性能问题；
3、不存在多线程切换而消耗CPU；
4、无法发挥多核CPU的优势，但可以采用多开几个Redis实例来完善；
5、Redis6.0之前是单线程的，Redis6.0之后开始支持多线程；

1.4、Redis持久化有几种方式？

redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
RDB持久化：
1、在指定的时间间隔内持久化
2、服务shutdown会自动持久化
3、输入bgsave也会持久化

AOF持久化:
1、以日志形式记录每个更新操作
2、Redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
保存策略：推荐（并且也是默认）的措施为每秒持久化一次，这种策略可以兼顾速度和安全性。
缺点：
1、比起RDB占用更多的磁盘空间
2、恢复备份速度要慢
3、每次读写都同步的话，有一定的性能压力
4、存在个别Bug，造成恢复不能

选择策略：如果对数据不敏感，可以选单独用RDB；不建议单独用AOF，因为可能出现Bug；如果只是做纯内存缓存，可以都不用。

1.5、缓存穿透、缓存雪崩、缓存击穿

1、缓存穿透
是指查询一个一定不存在的数据。由于缓存命不中时会去查询数据库，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。
解决方案：
1）是将空对象也缓存起来，并给它设置一个很短的过期时间，最长不超过5分钟
2）采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力
2、缓存雪崩
如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，就会造成缓存雪崩。
解决方案：尽量让失效的时间点不分布在同一个时间点
3、缓存击穿
是指一个key非常热点，在不停的扛着大并发，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
解决方案：可以设置key永不过期

1.6、锁

悲观锁
执行操作前假设当前的操作肯定（或有很大几率）会被打断（悲观）。基于这个假设，我们在做操作前就会把相关资源锁定，不允许自己执行期间有其他操作干扰。
乐观锁
执行操作前假设当前操作不会被打断（乐观）。基于这个假设，我们在做操作前不会锁定资源，万一发生了其他操作的干扰，那么本次操作将被放弃。Redis使用的就是乐观锁。

1.7、redis是单线程的，为什么那么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速；
2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4、使用多路I/O复用模型，非阻塞IO；
5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

2、HBase

2.1、HBase数据模型

HBase的特点是什么：
1、大，一个表可以有数十亿行，上百万列；
2、无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；HBase 定义表时只需要声明列族即可，不需要声明具体的列。这意味着，往 HBase 写入数据时，字段可以动态、按需指定。因此，和关系型数据库相比，HBase 能够轻松应对字段变更的场景。
3、面向列：面向列（族）的存储和权限控制，列（族）独立检索；
4、行
HBase 表中的每行数据都由一个 RowKey 和多个 Column（列）组成，数据是按照 RowKey的字典顺序存储的，并且查询数据时只能根据 RowKey 进行检索，所以 RowKey 的设计十分重要。
5、列
HBase 中的每个列都由 Column Family(列族)和 Column Qualifier（列限定符）进行限定，例如 info：name，info：age。建表时，只需指明列族，而列限定符无需预先定义。

2.2、HBase和Hive比较

1、是一种面向列族存储的非关系型数据库。
2、用于存储结构化和非结构化的数据
适用于单表非关系型数据的存储，不适合做关联查询，类似JOIN 等操作。
3、基于 HDFS
数据持久化存储的体现形式是 HFile，存放于 DataNode 中，被 ResionServer 以 region 的形式进行管理。
4、延迟较低，接入在线业务使用
面对大量的企业数据，HBase 可以直线单表大量数据的存储，同时提供了高效的数据访问速度。

2.3、 HBase优化

1. 高可用
在 HBase 中 HMaster 负责监控 HRegionServer 的生命周期，均衡 RegionServer 的负载，如果HMaster 挂掉了，那么整个 HBase 集群将陷入不健康的状态，并且此时的工作状态并不会维持太久。所以HBase 支持对 HMaster 的高可用配置。

2. 预分区
每一个 region 维护着 StartRow 与 EndRow，如果加入的数据符合某个 Region 维护的RowKey 范围，则该数据交给这个 Region 维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高HBase 性能。

3. RowKey设计
一条数据的唯一标识就是 RowKey，那么这条数据存储于哪个分区，取决于RowKey 处于哪个一个预分区的区间内，设计 RowKey的主要目的 ，就是让数据均匀的分布于所有的region 中，在一定程度上防止数据倾斜。RowKey 常用的设计方案：
（1）生成随机数、hash、散列值
（2）字符串反转
（3）字符串拼接
RowKey的三个原则
1）Rowkey的唯一原则
必须在设计上保证其唯一性。由于在HBase中数据存储是Key-Value形式，若HBase中同一表插入相同Rowkey，则原先的数据会被覆盖掉(如果表的version设置为1的话)，所以务必保证Rowkey的唯一性.

2）Rowkey的排序原则
HBase的Rowkey是按照ASCII有序设计的，我们在设计Rowkey时要充分利用这点。比如视频网站上对影片的弹幕信息，这个弹幕是按照时间排序展示视频里，这个时候我们设计的Rowkey要和时间顺序相关。

3）Rowkey的散列原则
我们设计的Rowkey应均匀的分布在各个HBase节点上。拿常见的时间戳举例，假如Rowkey是按系统时间戳的方式递增，Rowkey的第一部分如果是时间戳信息的话，具有相同前缀的Rowkey将被存储在相邻的物理位置上，将造成所有新数据都在一个RegionServer上堆积，也就是通常的Region热点问题， 热点发生在大量的client直接访问集中在个别RegionServer上（访问可能是读，写或者其他操作），导致单个RegionServer机器自身负载过高，引起性能下降甚至Region不可用，常见的是发生jvm full gc或者显示region too busy异常情况。

4. 内存优化
HBase 操作过程中需要大量的内存开销，毕竟 Table 是可以缓存在内存中的，一般会分配整个可用内存的70%给 HBase 的 Java 堆。但是不建议分配非常大的堆内存，因为 GC 过程持续太久会导致 RegionServer 处于长期不可用状态，一般 16~48G 内存就可以了，如果因为框架占用内存过高导致系统内存不足，框架一样会被系统服务拖死。

5. 基础优化
（1）允许在 HDFS 的文件中追加内容
（2）优化 DataNode 允许的最大文件打开数
（3）优化延迟高的数据操作的等待时间
（4）优化数据的写入效率
（5）设置 RPC 监听数量
（6）优化 HStore 文件大小
（7）优化 HBase 客户端缓存
（8）指定 scan.next 扫描 HBase 所获取的行数
（9）flush、compact、split 机制
当 MemStore 达到阈值，将 Memstore 中的数据 Flush 进 Storefile；compact 机制则是把 flush出来的小文件合并成大的 Storefile 文件。split 则是当 Region 达到阈值，会把过大的 Region一分为二。