冗余技术

图文并茂 RAID 技术全解 – RAID0、RAID1、RAID5、RAID100…… 　　RAID 技术相信大家都有接触过，尤其是服务器运维人员，RAID 概念很多，有时候会概念混淆。这篇文章为网络转载，写得相当不错，它对 RAID 技术的概念特征、基本原理、关键技术、各种等级和发展现状进行了全面的阐述，并为用户如何进行应用选择提供了基本原则，对于初学者应该有很大的帮助。 一、RAID 概述 　　1988 年美国加州大学伯克利分校的 D. A. Patterson 教授等首次在论文 “A Case of Redundant Array of Inexpensive Disks” 中提出了 RAID 概念 [1] ，即廉价冗余磁盘阵列（ Redundant Array of Inexpensive Disks ）。由于当时大容量磁盘比较昂贵， RAID 的基本思想是将多个容量较小、相对廉价的磁盘进行有机组合，从而以较低的成本获得与昂贵大容量磁盘相当的容量、性能、可靠性。随着磁盘成本和价格的不断降低， RAID 可以使用大部分的磁盘， “廉价” 已经毫无意义。因此， RAID 咨询委员会（ RAID Advisory Board, RAB ）决定用 “ 独立 ” 替代 “ 廉价 ” ，于时 RAID 变成了独立磁盘冗余阵列（ Redundant Array of

第4章 开发进阶 本章将介绍一些重中之重的数据库开发知识。 在数据库表设计中，范式设计是非常重要的基础理论，因此本章把它放在最前面进行讲解，而这其中又会涉及另一个重要的概念——反范式设计。 接下来会讲述MySQL的权限机制及如何固化安全。 然后介绍慢查询日志及性能管理的部分理念，并讲述数据库的逻辑设计、物理设计、导入导出数据、事务、锁等知识。 最后会提及 MySQL的一些非核心特性，并对于这些特性的使用给出一些建议。 4.1 范式和反范式 4.1.1 范式 什么是范式？ 范式是数据库规范化的一个手段，是数据库设计中的一系列原理和技术，用于减少数据库中的数据冗余，并增进数据的一致性。 数据规范化通常是将大表分成较小的表，并且定义它们之间的关系。这样做的目的是为了避免冗余存放数据，并确保数据的一致性。 添加、删除和修改数据等操作可能需要修改多个表，但只需要修改一个地方即可保证所有表中相关数据的一致性（由于数据没有冗余存放，修改某部分数据一般只需要修改一个表即可）。 由于数据分布在多个表之间，因此检索信息可能需要根据表之间的关系联合查询多个表。 数据规范化的实质是简单写、复杂读。 写入操作比较简单，对于不同的信息，分别修改不同的表即可；而读取数据则相对复杂，检索数据的时候，可能需要编写复杂的SQL来联合查询多个表。 常用的范式有第一、第二、第三范式，通常来说

为什么要编码 对于视频数据而言，视频编码的最主要目的是数据压缩。这是因为动态图像的像素形式表示数据量极为巨大，存储空间和传输带宽完全无法满足保存和传输的需求。 例如，图像的每个像素的三个颜色分量RGB各需要一个字节表示，那么每一个像素至少需要3字节，分辨率1280×720的图像的大小为2.76M字节。如果帧率为25帧/秒，那么传输所需的码率将达到553Mb/s，如果对于更高清的视频，如1080P、4k、8k视频，其传输码率更是惊人 为什么可以压缩 视频信息之所以存在大量可以被压缩的空间，是因为其中本身就存在大量的数据冗余 时间冗余：视频相邻的两帧之间内容相似，存在运动关系 空间冗余：视频的某一帧内部的相邻像素存在相似性 编码冗余：视频中不同数据出现的概率不同 视觉冗余：观众的视觉系统对视频中不同的部分敏感度不同 MPEG-1 MPEG组织制定的第一个视频和音频有损压缩标准，视频压缩算法于1990年定义完成。 1992年底，MPEG-1正式被批准成为国际标准。 MPEG－1曾经是VCD的主要压缩标准 MPEG1最大清晰度仅为352 X 288 视频压缩率为26：1 缺陷 压缩比还不够大 图像清晰度还不够高 传输图像的带宽有一定的要求，不适合网络传输 MPEG1的录像帧数固定为每秒25帧，不能丢帧录像，使用灵活性较差 MPEG-2 MPEG-2制定于1994年

Raid ​ RAID 独立磁盘冗余阵列，在本科学习时候学习过，记不清是组成原理还是操作系统，当时理解的不太清楚，现在研究生期间做存储相关项目，涉及到了Raid，于是查各种博客，为了以后便于后期查阅，写下这篇博客。 1. Raid的背景 ​ 在单机时代，采用单块磁盘进行数据存储和读写的方式，由于寻址和读写的时间消耗，导致I/O性能非常低，且存储容量还会受到限制。另外，单块磁盘极其容易出现物理故障，经常导致数据的丢失。因此大家就在想，有没有一种办法将多块独立的磁盘结合在一起组成一个技术方案，来提高数据的可靠性和I/O性能呢。 ​ 在这种情况下，RAID技术就应运而生了。 2. Raid是什么 RAID （ Redundant Array of Independent Disks ）即独立磁盘冗余阵列，简称为「磁盘阵列」，其实就是用多个独立的磁盘组成在一起形成一个大的磁盘系统，从而实现比单块磁盘更好的存储性能和更高的可靠性。 3. Raid有哪些 RAID方案常见的可以分为： RAID0 RAID1 RAID5 RAID6 RAID10 3.1 RAID0 RAID0 是一种非常简单的的方式，它将多块磁盘组合在一起形成一个大容量的存储。当我们要写数据的时候，会将数据分为N份，以独立的方式实现N块磁盘的读写，那么这N份数据会同时并发的写到磁盘中，因此执行性能非常的高。 RAID0

1. 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。 这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。 因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3. 基本表的性质 基本表与中间表、临时表不同，因为它具有如下四个特性： 原子性。基本表中的字段是不可再分解的。 原始性。基本表中的记录是原始数据（基础数据）的记录。 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 稳定性

移动互联网时代，海量的用户每天产生海量的数量，比如： 用户表 订单表 交易流水表 以支付宝用户为例，8亿；微信用户更是10亿。订单表更夸张，比如美团外卖，每天都是几千万的订单。淘宝的历史订单总量应该百亿，甚至千亿级别，这些海量数据远不是一张表能Hold住的。事实上MySQL单表可以存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW以下是最佳状态，因为这时它的BTREE索引树高在3~5之间。 既然一张表无法搞定，那么就想办法将数据放到多个地方，目前比较普遍的方案有3个： 分区； 分库分表； NoSQL/NewSQL； 既然一张表无法搞定，那么就想办法将数据放到多个地方，目前比较普遍的方案有3个： 分区； 分库分表； NoSQL/NewSQL； 说明：只分库，或者只分表，或者分库分表融合方案都统一认为是分库分表方案，因为分库，或者分表只是一种特殊的分库分表而已。NoSQL比较具有代表性的是MongoDB，es。NewSQL比较具有代表性的是TiDB。 Why Not NoSQL/NewSQL? 首先，为什么不选择第三种方案NoSQL/NewSQL，我认为主要是RDBMS有以下几个优点： - RDBMS生态完善； - RDBMS绝对稳定； - RDBMS的事务特性； NoSQL/NewSQL作为新生儿，在我们把可靠性当做首要考察对象时

https://blog.csdn.net/paolei/article/details/94390330 背景简介 　　对于大型应用后台系统来说，稳定性至关重要。目前越来越多的大型应用系统采用微服务架构，更加需要关注稳定性的技术能力建设。稳定性是服务系统基础能力的体现。 　　基础知识 　　在介绍稳定性技术策略主题之前，我们首先梳理一些基础概念和知识。 　　针对我们业务后台系统建设，任何大型业务后台系统绝对不是一蹴而就。它是伴随着业务不同阶段，不断进行演进的过程。如果经历过从 0 到 1 建设一个业务后台系统的同学，都会有类似的体会。 　　启动阶段 　　启动阶段，业务模型相对简单，用户量少，这时候我们可以将所有的系统模块耦合在一个工程里面，进行单机部署。这时候可能仅仅需要将业务系统与数据库进行隔离。 　　探索阶段 　　探索阶段，业务模型不断演进，用户量增加，单机服务能力瓶颈凸显。这时候就需要由单机服务部署向集群服务部署来优化，利用负载均衡将请求合理分配，减少单机服务压力。另外一个方面，数据量不断的增加，也需要考虑针对数据来进行水平的扩展(主从部署，读写分离)。 　　在这一阶段，我们仅仅是做了集群扩展，但所有的业务代码都在同一个工程维护，所有的数据信息都在同一个数据库中存储。随着团队的扩充与业务交互不断复杂化，在工程维护上存在很大的风险，工程研发效率受到制约

对于语音通信而言，语音码率较低，添加适当冗余是对抗网络丢包的常见方式。冗余方式有多种，包括 RED ， FEC 等都是冗余的一种，如果冗余份数较多，可以采取交织的方式实现。 RFC 3350 是RTP的基础标准协议， RFC 2198 是冗余数据RTP封装的标准协议， RFC 5109 是添加FEC数据的RTP封装标准协议。 RTP格式(RFC 3350) 文档地址： RTP: A Transport Protocol for Real-Time Applications RTP(Real-time Transport Protocol, 实时传输协议)是互联网上常见的处理媒体数据流的网络协议，包括单播和多播等多种场景下的网络环境中媒体数据的传输。RTP是一种应用层协议，一般使用UDP作为底层协议实现数据传输，但并不强制底层协议的选择。RTP不提供任何机制来保证实时的传输和服务质量保证，而是由底层的服务来完成。也就是说，它不保证可靠传输和按序传输，不假定下层网络是否可靠，不限制按照顺序传送数据包。 RTP一般与RTCP同时出现，端口号相邻。一般而言，RTP负责传输数据，RTCP用于传输控制信息，比如提供数据传输质量的反馈。RTCP为每个RTP源提供一个固定的识别符 CNAME 。当SSRC因重启或者冲突发生改变时，可以更加 CNAME 跟踪参与者；或者用 CNAME

一、什么是高可用 高可用HA （ High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指， 通过设计减少系统不能提供服务的时间 。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。 很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。 二、如何保障系统的高可用 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。 方法论上，高可用保证的原则是“集群化”，或者叫“冗余” ：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。 保证系统高可用，架构设计的核心准则是：冗余。 有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是 通过“自动故障转移”来实现系统的高可用 。 接下来我们看下典型互联网架构中，如何通过 冗余+自动故障转移

原创 2016-12-05 58沈剑 架构师之路 一、什么是高可用 高可用HA （ High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。 很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。 二、如何保障系统的高可用 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。 保证系统高可用，架构设计的核心准则是：冗余。 有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。