Linux——中间件、数据库（理论）

本文主要是介绍Linux——中间件、数据库（理论），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

中间件：

缓存服务：常规的NOsql （非关系型数据）memcached ectd redis hbase
加速服务： squid （反向代理服务器） varnish nginx也支持缓存功能
消息队列： rabbitmq Amq
专门用于数据库优化的应用，以MySQL为例 oneproxy（读写分离和分表） mha（高可用读写分离）
日志收集和分析： elk

选择关系型数据库的利与弊：

利：

容易理解：可由二维表结构来逻辑表达，相对网状、层次等其他模型更加容易被理解。严格遵循数据格式与长度规范，数据以行为单位，一行数据表示一个实体信息，每一行数据的属性都是相同的。存放的数据更加有逻辑性。

ER表实体属性关系

2、事务特性：支持 ACID 特性，可以维护数据之间的一致性，这是使用关系数据库非常重要的一个理由。

3、操作方便：通用的 SQL 语言使得操作关系型数据库非常方便，支持 join 等复杂查询，Sql + 二维关系是关系型数据库最无可比拟的优点，这种易用性非常贴近开发者。

4、数据稳定：数据持久化到磁盘，没有丢失数据风险。

5服务稳定：最常用的关系型数据库产品 MySql、Oracle 服务器性能卓越，服务稳定，通常很少出现宕机异常。

问题：

1、高并发下数据库瓶颈明显：数据按行存储，即使只针对某一列进行运算，也会将整行数据从存储设备中读入内存，导致 IO 较高。写入更新频繁的情况下，数据库往往会出现 CPU 飙高、Sql 执行慢、客户端报数据库连接池不够等异常情况，且性能瓶颈通过加 CPU、换固态硬盘、继续买服务器加数据库做分库等方式处理 ROI 不高，受限于其本身的特点，可能花了很多钱都未必能达到想要的效果。因此例如万人秒杀这种场景，我们绝对不可能通过数据库直接去扣减库存，需要做好流量漏斗。

2、为维护数据一致性付出的代价大：数据一致性是关系型数据库的核心，但是同样为了维护数据一致性的代价也非常大。SQL 标准为事务定义了不同的隔离级别，从低到高依次是读未提交、读已提交、可重复度、串行化，事务隔离级别越低，可能导致的并发异常越多，但是能提供的并发能力越强。那么为了保证事务一致性，数据库就需要提供并发控制与故障恢复两种技术，前者用于减少并发异常，后者可以在系统异常的时候保证事务与数据库状态不会被破坏。对于并发控制，其核心思想就是加锁，无论是乐观锁还是悲观锁，只要提供的隔离级别越高，那么读写性能必然会受影响。

3、为维护索引付出的代价大：为了提供丰富的查询能力，通常热点表都会有多个二级索引，一旦有了二级索引，数据的新增必然伴随着所有二级索引的新增，数据的更新也必然伴随着所有二级索引的更新，这不可避免地降低了关系型数据库的读写能力，且索引越多读写能力越差。除了数据文件不可避免地占空间外，索引占的空间其实也并不少。

4、水平扩展后带来的种种问题难处理：随着业务规模扩大，一种方式是对数据库做分库，做了分库之后，数据迁移（1 个库的数据按照一定规则打到 2 个库中），跨库 join、分布式事务处理都是需要考虑的问题，尤其是分布式事务处理，业界当前都没有特别好的解决方案。

5、全文搜索功能弱：例如 like “% 新年快乐 %”，只能搜索到 “新年快乐，爱大家”，无法搜索到 “新年真是太快乐了，爱大家” 这样的文本，即不具备分词能力，且 like 查询在 “% 新年快乐” 这样的搜索条件下，无法命中索引，将会导致查询效率大大降低。

6表结构扩展不方便：由于数据库存储的是结构化数据，因此表结构 schema 是固定的，扩展不方便，如果需要修改表结构，需要执行 DDL（data definition language）语句修改，修改期间会导致锁表，部分服务不可用。

以上6点其实可以简单的总结为：