冗余系统

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作为新生儿，在我们把可靠性当做首要考察对象时

VIM命令解释总结 在 Linux系统中配置应用服务，实际上就是在修改它的配置文件（配置文件可能有多个，其中包含不同的参数）这些都要通过文本编辑器来完成。 所以 文本编辑器就非常必要了， vim文本编辑器，是 vi 编辑器的升级版 。 Vim能够得到这么多厂商与用户的认可，原因就是在Vim编辑器中有三种模式—— 命令模式 、 末行模式 和 编辑模式 ，分别又有多种不同的命令快捷键组合，很大的提高了工作效率，用习惯后会觉得非常的顺手。要想在文本操作时更加高效率，我们必需先搞清 Vim编辑器的三种模式的操作不同与切换方法。 命令模式：控制光标移动，可对文本进行删除、复制、粘贴等工作。 输入模式：正常的文本录入。 末行模式：保存、退出与设置编辑环境。 记住每次运行 vim编辑器后都默认是“ 命令模式 ”，需要先进入到“ 输入模式 ”后再进行编写文档的工作，而每次编辑完成需先返回到“ 命令模式 ”后再进入“ 末行模式 ”对文本的保存或退出操作。 这里是最常用的快捷键命令， “输入模式”没有特殊技巧。 vim编辑器的命令模式中常用的快捷键 命令 作用 dd 删除(剪切)光标所在整行。 5dd 删除(剪切)从光标处开始的5行。 yy 复制光标所在整行。 5yy 复制从光标处开始的5行。 p 将之前删除（dd）或复制（yy）过的数据粘贴到光标后。 /字符串 在文本中从上至下搜索该字符串。

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

Raid0描述：最大能力保证速度 Raid0又称为stripe（条带化）或striping（条带模式），他在所有RAID级别中具有最高的存储性能 Raid0提高存储性能的原理是把连续的数据分散到多个磁盘上存取。这样，系统有数据读写请求就可以再多个磁盘并行的执行，每个磁盘读写属于它自己的那部分数据请求。这种数据上的并行操作可以充分利用总线的带宽，显著提高磁盘整体存取性能。 要制作raid0要求至少1块物理磁盘，一般用来做RAID的不同磁盘大小最好一样（可以充分发挥并行优势）；而数据分散存储于不同的磁盘上，再读写的时候可以实现并发，所以，raid0读写性能最好，但是没有容错功能，即任何一个磁盘的损坏会导致整个raid的全部数据丢失；生产中使用单盘，要做成raid0，否则无法使用。 Raid0的缺点是不具备数据冗余，因此一旦用户数据损坏，损坏的数据将无法的到恢复，raid0具有的特点：使其特别使用户对性能要求较高，而对数据安全不太在乎的领域。 生产场景： 1、 负载浚航集群下面的多个相同的RS节点服务器 2、 分布式文件存储下面的主节点或CHUNK SERVER 3、 Mysql主从复制的多个slave服务器 4、 对性能要求很高，对冗余要求很低的相关业务。 关注点 描述 容量 是四块盘加起来的容量，再raid级别中具备最该的存储性能，原理是把连续的数据分散到多个磁盘上存取 性能

一、什么是高可用 高可用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能够顶上。 保证系统高可用，架构设计的核心准则是：冗余。 有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。

Centos 7 冗余备份磁盘配置介绍 我们上一盘介绍了Centos 7 磁盘阵列配置介绍，今天继续上一篇的配置介绍，通过上一篇的配置介绍我们发现了一个问题。，运维人员需要在硬盘硬件出现故障后，手动增加新的硬盘进去，这样很不方便，比如初始化RAID5整列是直接给与4块硬盘，其中一块硬盘设备用于在阵列某个硬盘出现故障自动替换上去，这样是不是很方便呢，那我们今天就介绍一下配置冗余备份磁盘，具体见下： 先将量磁盘系统卸载 umount /dev/md0 停止该阵列设备，彻底的停用 mdadm -S /dev/md0 mdadm -D /dev/md0 我们创建一个RAID5并且设置一块备份故障盘 mdadm -Cv /dev/md0 -n 3 -l 5 -x 1 /dev/sdb /dev/sdc /dev/sdd /dev/sde 查看阵列 mdadm /D /dev/md0 我们等待了一会后，发现rebuild完成了，然后再次查看 然后我们接下来就是格式化ext4 mkfs.ext4 /dev/md0 因为我们前面设置过fstab文件，所以现在可以直接挂在 mount -a 我们将/dev/sdb设备设置为故障并且移除阵列 mdadm /dev/md0 -f /dev/sdb 接下来我们查看是否自动将sde直接顶替上去了 mdadm -D /dev/md0 来源： 51CTO 作者：

引言 本文通过对卷类型的分析对比，来帮助读者选取生产环境最符合服务的挂载存储，命令可结合《 glusterfs详解及kubernetes 搭建heketi-glusterfs 》进行实验，下面进入正题 几种卷类型 基础卷：布式卷（distribute）、条带卷（stripe）、复制卷（replica）、纠错卷（Dispersed ） 复合卷：分布式条带卷（distribute stripe）、分布式复制卷（distribute replica）、条带复制卷（stripe replica）、分布式条带复制卷（distribute stripe） 一、基础卷 以下创建挂载卷，均可通过以下命令进行查看、启用、停止、删除 #查看已创建挂载卷 gluster volume info #启动挂载卷 gluster volume start gv0 #删除前，先停止挂载卷 gluster volume stop gv0 #删除挂载卷 gluster volume delete gv0 1. 布式卷（distribute voulme） 分布式模式，既DHT，是GlusterFS的默认模式，在创建卷时，默认选项是创建分布式卷。在该模式下，并没有对文件进行分块处理，而是通过hash算法分布到所有brick server上，只是扩大了磁盘空间，类似window中的跨区卷 distribute