数据库应用与设计-大型数据库系统架构设计方法

第三章大型数据库系统应用设计方法可扩展性、高可用性及负载均衡基本概念可扩展性（Scalability|伸缩性）：在一些大的系统中，预测最终用户的数量和行为是非常困难的，可扩展性是指系统适应不断增长的用户数的能力。提高这种并发会话能力的一种最直观的方式就增加资源（CPU，内存，硬盘等），集群是解决这个问题的另一种方式，它允许一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务。高可用性（Highavailability）：单一服务器的解决方案并不是一个健壮方式，因为容易出现单点失效。像银行、账单处理这样一些关键的应用程序是不能容忍哪怕是几分钟的死机。它们需要这样一些服务在任何时间都可以访问并在可预期的合理的时间周期内有响应。集群方案通过在集群中增加的冗余的服务器，使得在其中一台服务器失效后仍能提供服务，从而获得高的可用性。负载均衡（Loadbalancing）：负载均衡是集群的一项关键技术，通过把请求分发给不同的服务器，从而获得高可用性和较好的性能。一个负载均衡器可以是从一个简单的Servlet或Plug-Ins（例如一个Linuxbox利用ipchains来实现），到昂贵的内置SSL加速器的硬件。除此之外，负载均衡器还需执行一些其他的重要任务，如“会话胶粘”让一个用户会话始终存在一个服务器上，“健康检查”用于防止将请求分发到已失效的服务器上。有些负载均衡器也会参与我们下面将要谈到“失效转移”过程。基本概念容错（Faulttolerance）：高可用性意味着对数据正确性的要求不那么高。在J2EE集群中，当一个服务器实例失效后，服务仍然是有效的，这是因为新的请求将被冗余服务器处理。但是，当一个请求在一个正在失效的服务器中处理时，可能得到不正确的结果。不管有多少个错误，容错的服务应当能确保有严格的正确的行为。失效转移（Failover）：失效转移是集群中用来获取容错能力的另一项关键的技术。当一个结点失效后，通过选择集群中的另一个结点，处理将会继续而不会终止。转移到另一个结点可以被显式的编码，或是通过底层平台自动地透明地路由到另一个服务器。等幂方法（Idempotentmethods）：等幂方法是指这样一些方法：重复用相同的参数调用都能得到相同的结果。这些方法不会影响系统状态，可以重复调用而不用担心改变系统。例如：getUsername()就是等幂的，而deleteFile就不是。当我们讨论HTTPSession失效转移和EJB失效转移时，它是一个重要的概念。讨论的背景主题数据库基本问题调查关系数据库的基本背景ACID基本概念解析范式问题解析（Normalization）数据库基本问题调查大家都使用过哪些数据库？哪些内容是数据库系统的关键点？常见的数据存储传统的数据库系统•Oracle•DB2、SQLServer•MySQL、PosgreSQL分布式数据库•GoogleSpanner&BigTable&MegaStore•OceanBase、Hbase缓存服务器＆KeyValueStore•Tair•Memcached•Redis数据库的主要特性ACID•原子性（Atomicity）•完整性（Consistency）•隔离性（Isolation）•持久性（Durability）Relation＆SQL•StructuredQueryLanguage（即SQL）•ARelationalModelofDataforLargeSharedDataBanks（ByEdgarCodd）RDBMS之前的数据库的问题不支持数据独立性数据库与应用系统之间的强耦合应用系统的复杂度应用系统本身的规模较小（性价比？）关系数据库的主要业务场景Billing（记账类业务，电信、银行）Booking（订票类业务，航空）Inventory（库存管理，零售）这些业务的共同特征是什么？关系数据库的关系来自哪里？这是关系的一个来源另一个来源是NormalizationACID的基础概念Transaction的概念借自ContractLaw•一手交钱、一手交货（Atomicity）•不会出现库存为负，也不会出现资金为负的情况（Consistency）•可同时与多人进行交易（Isolation）•离柜概不负责（Durability）Atomicity•要么全部成功，要么全不成功Consistency•写入数据库的数据必须满足所有定义的约束规则（主键、唯一键、外键等约束）Isolation•确保并发执行的事务就如同串行执行的事务一样，保证系统状态（state）的一致性。Durability•一旦提交，哪怕出现掉电、Crash也不会丢数据几个基础概念Write-AheadLogRedo•Logical•Physical•PhysiologicalUndo事务槽－事务标识SCN–系统变更统一时间戳（逻辑时钟）如何实现原子性一个简单购物场景•A卖一件衣服给B•A的衣服库存-1•A的资金+N•B的衣服库存+1•B的资金-N如何实现原子性（2）事务槽为变更入口，单一入口（原子）每个变更的记录都包含事务槽信息数据库中如何保证C通过ReadDirty与锁来解决PK/UK通过Ref检查来解决FK的问题（需要Index）通过PreCommittrigger来做Null以及Check数据库中如何保证I锁控制•不同粒度的锁（表级、块级、记录级）•不同维度的锁（数据相关锁，内存相关锁）MVCC•SnapshotIsolation•BlockImage+SCN+UndoImage判断差别在于读取哪个时间点的Snapshot数据库中如何保证DLogbeforeDataLGWRbeforeDBWnFlushLogonCommit•DurabilityOnCommitCheckpointBeforeRedoLogFileReuseACID的代价不同的Isolation对应不同的代价•Serialiazability•ReadCommitted(ThroughSnapshot)•ReadDirty?（没有并发控制）不同的Durability级别•FlushonCommit•FlushonTimeout(TimeRange)•FlushonBatch(commitscount?)主题数据库基本问题调查关系数据库的基本背景ACID基本概念解析范式问题解析（Normalization）数据库的扩展性浅析常见数据库系统回顾NORMALIZATION先做个小游戏用笔记录下•学生名单、老师姓名、讲师简介、课程名称、课程简介调整下•老师（黄晋汤庸）以及对应的老师简介再次调整下•课程（数据库概论分布式数据库原理）＆简介NORMALIZATION解决的问题更新一个源头不会出现异常每份数据只有一个源头•如何保证多份数据的一致性？•一份数据有多少个源头？同一份数据被重复了多少次？•对应的存储空间？•为了存储耗费的其它资源？NORMALIZATION带来的问题表之间的依赖（关系依赖，耦合）表关联的成本（关联开销，可能的IO开销）系统扩展的复杂度（解耦合）如何权衡NORMALIZATION尽量不要对静态数据做Normalization•除非你希望节约存储空间考虑范式化Vs反范式化的投入产出为什么很多IT新人喜欢Normalization•那是因为他们的老师告诉他们需要建议•适度的使用•关键在于判断业务之间的耦合性主题数据库基本问题调查关系数据库的基本背景ACID基本概念解析范式问题解析（Normalization）数据库的扩展性浅析常见数据库系统回顾一个小实验如何将2个人从这里送到大学城？如何将5个人从这里送到大学城？如何将50个人从这里送到大学城？如何将500个人从这里送到大学城？如何将5000个人从这里送到大学城？如何将50000个人从这里送到大学城？数据库的扩展性问题数据库架构、系统架构在于：•如何满足如下的要求检索问题•Relation并发问题•Isolation•Consistency(UK)一致性问题•Isolation速度问题•Performance,Durability+Isolation数据库检索问题如何从班级的联系方式中找到XX的电话号码？如何从公司的联系方式中找到XX的电话号码？如何从移动公司的系统中找到XX的电话号码？如何从移动、电信、联通的数据库找到XX的电话号码？数据库的并发问题同时有多个人要购买手机号？如何保证大家购买的不是同一个手机号？如何支持几百、几千、几万人同时购买手机号？数据库的一致性问题如何保证大家看到的库存有效？如何保证读取的信息是准确的？库存的变更如何实时的提供给每一个人看到？数据库的性能问题？如何快速的让1个人买到号码？•有多快？如何快速的让10个人买到号码？•要不要排队？•一个服务员？•一个营业厅？PERFORMANCEVSSCALABILITY1.当只有一个人访问时，速度如何？2.当有很多人访问时，速度如何？•大家都同样快？如果满足1•表示Performance很好？如何能较好的满足2•表示系统有较好的Scalability一致性问题再探讨新浪发的微薄需要强一致吗？ITPUB的论坛需要强一致吗？当当的图书描述信息需要强一致吗？12306的火车票库存信息需要强一致吗？支付宝/财付通的账户余额需要强一致吗？中行信用卡/招商银行卡的账户信息需要强一致吗?讨论扩展性数据库系统的扩展性•Scale（扩展）就是让我们的数据库能够提供更强的服务能力，更强的处理能力。•Scalable（可扩展）则是表明数据库系统在通过相应升级（包括增加单机处理能力或者增加服务器数量）之后能够达到提供更强处理能力。在理论能上来说，任何数据库系统都是Scalable的，只不过是所需要的实现方式不一样而已。•Scalability（扩展性）则是指一个数据库系统通过相应的升级之后所带来处理能力提升的难易程度。虽然理论上任何系统都可以通过相应的升级来达到处理能力的提升，但是不同的系统提升相同的处理能力所需要的升级成本（资金和人力）是不一样的，这也就是我们所说的各个数据库应用系统的Scalability存在很大的差异。数据库系统的扩展性•ScaleUp则是指纵向的扩展，向上扩展，也就是通过增加当前处理节点的处理能力来提高整体的处理能力，是通过升级现有服务器的配置，如增加内存，增加CPU，增加存储系统的硬件配置，或者是直接更换为处理能力更强的服务器和更为高端的存储系统。•ScaleOut就是指横向的扩展，向外扩展，也就是通过增加处理节点的方式来提高整体处理能力，即通过增加机器来增加整体的处理能力。SCALEUP优缺点•ScaleUp优点：•处理节点少，维护相对简单；•所有数据都集中在一起，应用系统架构简单，开发相对容易；•ScaleUp缺点•高端设备成本高，且竞争少，容易受到厂家限制；•受到硬件设备发展速度限制，单台主机的处理能力总是有极限的，容易遇到最终无法解决的性能瓶颈；•设备和数据集中，发生故障后的影响较大；SCALEOUT优缺点•ScaleOut优点•成本低，很容易通过价格低廉的PCServer搭建出一个处理能力非常强大的计算集群；•不容易遇到瓶颈，因为很容易通过添加主机增加处理能力；•单个节点故障对系统整体影响较小；也存在缺点，更多的计算节点，大部分时候都是服务器主机，这自然会带来整个系统维护复杂性的提高，在某些方面肯定会增加维护成本，而且对应用系统的架构要求也会比ScaleUp更高，需要集群管理软件的配合。•ScaleOut缺点•处理节点多，造成系统架构整体复杂度提高，应用程序复杂度提高；•集群维护难以程度更高，维护成本更大；SCALABILITY很好的数据库应用系统遵循的原则•事务相关性最小化原则•数据一致性原则•高可用及数据安全原则事务相关性最小化原则•分布式的架构带来分布式事务的问题•在传统的集中式数据库架构中，事务的问题非常好解决，可以完全依赖数据库本身非常成熟的事务机制来保证。但是一旦我们的数据库作为分布式的架构之后，很多原来在单一数据库中所完成的事务现在可能需要跨多个数据库主机