nosql

一、前言 ​　　随着社会的发展，技术的进步，以前的大型机架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的分布式架构，从大型机到分布式，经历了好几个阶段，我们弄明白各个阶段的架构，才能更好地理解和体会分布式架构的好处，那么本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。 二、背景说明 ​　　我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的。 在这个过程中，开发模式、技术架构等都会随着迭代发生非常大的变化。 而针对不同业务特征的系统，各自都会有自己的侧重点，例如像淘宝这类的网站，要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站，要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。 ​　　下面我们来简单模拟一个架构演变过程。 我们以 javaweb 为例，来搭建一个简单的电商系统，从这个系统中来看系统的演变过程。要注意的是接下来的演示模型， 关注的是数据量、访问量提升，网站结构的变化， 而不关注具体业务的功能点。其次，这个过程是为了让大家能更好的了解网站演进过程中的一些问题和应对策略。

最开始的网站架构 最初业务量不大，访问量小，此时的架构，应用程序、数据库、文件都部署在一台服务器上，有些甚至仅仅是租用主机空间 1. 应用、数据、文件分离 将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。 2. 利用缓存改善网站性能 大部分网站访问都遵循28原则,即80%的访问请求，最终落在20%的数据上,所以我们可以对热点数据进行缓存，减少热点数据的访问路径，提高用户体验。缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理。 2.1 本地缓存 本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。OSCache就是常用的本地缓存。 2.2 分布式缓存 分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。 2.3 反向代理 部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有缓存数据才会继续访问应用服务器获取，这样做减少了获取数据的成本。反向代理有Squid，Nginx。 2.4 CDN 假设我们的服务器都部署在杭州的机房，对于浙江的用户来说访问是较快的

最开始的网站架构 最初业务量不大，访问量小，此时的架构，应用程序、数据库、文件都部署在一台服务器上，有些甚至仅仅是租用主机空间 1. 应用、数据、文件分离 将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。 2. 利用缓存改善网站性能 大部分网站访问都遵循28原则,即80%的访问请求，最终落在20%的数据上,所以我们可以对热点数据进行缓存，减少热点数据的访问路径，提高用户体验。缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理。 2.1 本地缓存 本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。 2.2 分布式缓存 分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。 2.3 反向代理 部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有缓存数据才会继续访问应用服务器获取，这样做减少了获取数据的成本。 2.4 CDN 假设我们的服务器都部署在杭州的机房，对于浙江的用户来说访问是较快的，而对于北京的用户访问是较慢的

分布式理论（一） CAP 理论 一． CAP 理论前言 CAP 原则又称为 CAP 理论，主要思想是在任何一个分布式系统中都无法同时满足 CAP 。 C （ Consistency ）：表示一致性，所有的节点同一时间看到的是相同的数据。 A （ Avaliablity ）：表示可用性，不管是否成功，确保一个请求都能接收到响应。 P （ Partion Tolerance ）：分区容错性，系统任意分区后，在网络故障时，仍能操作。 如上所述，正如 Gilbert 认为， 一致性 其实就是关系型数据库所讲的 ACID ，一个用户请求要么是成功，要么是失败的，不能有处于一个中间状态；一旦一个事务完成，将来所有事务都必须基于这个完成后的状态；未完成的事务不会互相影响；一旦一个事务完成，就是持戒的。 可用性 其实就是对于一个系统而言，所有的请求都应该 “成功”并且收到“响应”。 分区容错性 其实就是指分布式系统的容错性，一个节点出现了故障，不影响整个集群的正常使用。 二． CAP 理论介绍 如图，在一个网络中， N1 和 N2 即分布式系统中的两个节点，他们都共享数据块 V ，其中有一个值是为 V0 。 l 在满足一致性的时候， A 中的 V0 应该和 B 中的 V0 保持一致的，即 V0=V0 l 在满足可用性的时候，无论请求访问 A 或者是 B 都应该得到响应。 l 在满足分区可用性的时候

在单机的数据库系统之中，我们很容易实现一套满足ACID 特性的 事务处理系统， 事务的一致性不存在问题。 但是在分布式系统之中，由于数据分布在不同的主机结点上，如何对着些数据进行分布式的事务处理就具有非常大的挑战，CAP 理论的出现，让我们对于分布式事务的一致性有了另外一种看法。 什么是CAP 理论？ 在计算机科学理论，CAP 理论 （也称Brewer 定理） 又有称为 CAP原则，CAP定理，是由计算机科学家Eric Brewer 在 2000 年 提出的 ，其理论观点是， 在分布式计算机系统中，不可能存在同时提供 以下全部三个保证。 Consistency（一致性）： 所有节点同一时间看到的是相同的数据。在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） Availability（可用性）：不管是否成功，确保每一个请求都能接收到响应。在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） Partition tolerance（分区容错性）：系统任意分区后，在网络故障时，仍能操作。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 　　 CAP原则是NOSQL数据库和分布式系统的基石。 为什么说CAP

摘要： GaussDB(for Redis)（下文简称 高斯Redis ）是华为云数据库团队自主研发的兼容Redis协议的云原生数据库，该数据库采用计算存储分离架构，突破开源Redis的内存限制，可轻松扩展至PB级存储。 本文将从存储架构、四大特性、竞争力、应用场景等方面进行介绍。 存储架构 高斯Redis基于计算存储分离架构，计算层实现热数据缓存，存储层实现全量数据的落盘，中间通过RDMA高速网络互连，通过算法预测用户的访问规律，实现数据的自动冷热交换，最终达到极致的性能提升。 四大特性 该架构基于华为内部强大且广泛使用的自研分布式存储系统DFV，实现了一套Share Everything的云原生架构，充分发挥了云原生的弹性伸缩、资源共享的优势，使得高斯Redis具备强一致、秒扩容、低成本、超可用的四大特点，完美避开了开源Redis的主从堆积、主从不一致、fork抖动、内存利用率只有50%、大key阻塞、gossip集群管理等问题。 强一致 数据复制是存储的事情，因此专业的事情交给专业的团队来做。通过分布式存储DFV，高斯Redis轻松实现了3副本强一致，并可轻松支持6副本，为业界首创。 在强一致架构下，用户再也不用担心开源Redis的主从堆积，带来的丢数据、不一致、OOM等极端问题，更不用担心业务出错，比如计数器、限流器、访问统计、hash字段等不一致。 秒扩容

先问一下，你们公司的主存储技术是什么？估计很多人答案都是 MySQL。 但，SQL 还够用吗？ 那你再想一下，你当下的业务用 MySQL 做主存储还能支撑多久，如果业务量暴增，你能怎么做，愿意花多大价钱进行扩容？ 如果遇到容量和性能问题就升级服务器，开发也太好做了。你要是只能想到这个答案，那今天要聊的这个话题——分布式数据库，对你来说跨度还挺大。 1分钟快速认识分布式数据库 分布式数据库其实就是多个节点的数据库共同形成一个全局数据库来提供服务，优点基本都在 以上对比里了， 访问速度更快，更强的可扩展性，支持更高的并发访问量。 各大互联网公司，甚至金融行业都开始使用分布式数据库，阿里巴巴有 OceanBase 风光无两，TiDB 在银行大受欢迎，各种云厂商相继发布重量级产品。 （2021 年数据大会上，阿里云发布了分布式数据库使用率统计图） 分布式数据库，是必然趋势 这个图展示了数据库技术这些年的技术探索，其实就是个逐渐“分布式”的过程。从 SQL 到 NewSQL 的技术探索，让分布式数据库能够满足两大核心要求： 完整的 ACID 支持，分布式事务和数据一致性保证； SQL 语法的完全兼容，对 SQL 业务的完整支持。 技术的完善性，加上学术与商业氛围浓厚， 分布式数据库已经是大势所趋。 有人会说，现在公司的数据库技术就挺成熟，有必要跟风追新吗？ 公司做技术选型和架构设计

MySQL索引优化分析 为什么你写的sql查询慢？为什么你建的索引常失效？通过本章内容，你将学会MySQL性能下降的原因，索引的简介，索引创建的原则，explain命令的使用，以及explain输出字段的意义。助你了解索引，分析索引，使用索引，从而写出更高性能的sql语句。还在等啥子？撸起袖子就是干！ 案例分析 我们先简单了解一下 非关系型数据库 和 关系型数据库 的区别。 MongoDB是NoSQL中的一种。NoSQL的全称是Not only SQL，非关系型数据库。它的特点是 性能高 ， 扩张性强 ， 模式灵活 ，在高并发场景表现得尤为突出。但目前它还只是关系型数据库的补充，它在数据的一致性，数据的安全性，查询的复杂性问题上和关系型数据库还存在一定差距。 MySQL是关系性数据库中的一种， 查询功能强 ， 数据一致性高 ， 数据安全性高 ， 支持二级索引 。但性能方面稍逊与MongoDB，特别是百万级别以上的数据，很容易出现查询慢的现象。这时候需要分析查询慢的原因，一般情况下是程序员sql写的烂，或者是没有键索引，或者是索引失效等原因导致的。 公司ERP系统数据库主要是MongoDB（最接近关系型数据的NoSQL），其次是Redis，MySQL只占很少的部分。现在又重新使用MySQL，归功于阿里巴巴的奇门系统和聚石塔系统。考虑到订单数量已经是百万级以上

为什么你写的sql查询慢？为什么你建的索引常失效？通过本章内容，你将学会MySQL性能下降的原因，索引的简介，索引创建的原则，explain命令的使用，以及explain输出字段的意义。助你了解索引，分析索引，使用索引，从而写出更高性能的sql语句。还在等啥子？卷起袖子就是干！ 案例分析 我们先简单了解一下 非关系型数据库 和 关系型数据库 的区别。 MongoDB是NoSQL中的一种。NoSQL的全称是Not only SQL，非关系型数据库。它的特点是 性能高 ， 扩张性强 ， 模式灵活 ，在高并发场景表现得尤为突出。但目前它还只是关系型数据库的补充，它在数据的一致性，数据的安全性，查询的复杂性问题上和关系型数据库还存在一定差距。 MySQL是关系性数据库中的一种， 查询功能强 ， 数据一致性高 ， 数据安全性高 ， 支持二级索引 。但性能方面稍逊与MongoDB，特别是百万级别以上的数据，很容易出现查询慢的现象。这时候需要分析查询慢的原因，一般情况下是程序员sql写的烂，或者是没有键索引，或者是索引失效等原因导致的。 公司ERP系统数据库主要是MongoDB（最接近关系型数据的NoSQL），其次是Redis，MySQL只占很少的部分。现在又重新使用MySQL，归功于阿里巴巴的奇门系统和聚石塔系统。考虑到订单数量已经是百万级以上，对MySQL的性能分析也就显得格外重要。