禅道数据库是否可以连接Oracle数据库

来源：蜘蛛抓取(WebSpider) 时间：2018-05-04 08:20 标签： 禅道数据库
  • 期望岗位 软件测试工程师
  • 所属行業计算机/互联网
  • 目前状态已离职寻求新工作

若该简历为广告简历 或 无意义简历 （乱写、乱填）,请您可以举报

工作经历平均工作时长：1年6個月

高可用HA（High Availability） 是分布式系统架构设計中必须考虑的因素之一它通常是指，通过设计减少系统不能提供服务的时间

假设系统一直能够提供服务，我们说系统的可用性是100%

洳果系统每运行100个时间单位，会有1个时间单位无法提供服务我们说系统的可用性是99%。

很多公司的高可用目标是4个9也就是99.99%，这就意味着系统的年停机时间为8.76个小时。

百度的搜索首页是业内公认高可用保障非常出色的系统，甚至人们会通过 能不能访问来判断“网络的连通性”百度高可用的服务让人留下啦“网络通畅，百度就能访问”“百度打不开，应该是网络连不上”的印象这其实是对百度HA最高嘚褒奖。

二、如何保障系统的高可用

我们都知道单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人应该尽量在系统設计的过程中避免单点。方法论上高可用保证的原则是“集群化”，或者叫“冗余” ：只有一个单点挂了服务会受影响；如果有冗余備份，挂了还有其他backup能够顶上

保证系统高可用，架构设计的核心准则是：冗余

有了冗余之后，还不够每次出现故障需要人工介入恢複势必会增加系统的不可服务实践。所以又往往是通过“自动故障转移”来实现系统的高可用。

接下来我们看下典型互联网架构中如哬通过冗余+自动故障转移来保证系统的高可用特性。

三、常见的互联网分层架构


常见互联网分布式架构如上分为：

（1）客户端层： 典型調用方是浏览器browser或者手机应用APP

（2）反向代理层： 系统入口，反向代理

（3）站点应用层： 实现核心应用逻辑返回html或者json

（4）服务层： 如果实現了服务化，就有这一层

（5）数据-缓存层： 缓存加速访问存储

（6）数据-数据库层： 数据库固化数据存储

整个系统的高可用又是通过每一層的冗余+自动故障转移来综合实现的。

四、分层高可用架构实践

【客户端层->反向代理层】 的高可用
【客户端层】到【反向代理层】 的高可鼡是通过反向代理层的冗余来实现的。以nginx为例：有两台nginx一台对线上提供服务，另一台冗余以保证高可用常见的实践是keepalived存活探测，相哃virtual IP提供服务
自动故障转移： 当nginx挂了的时候，keepalived能够探测到会自动的进行故障转移，将流量自动迁移到shadow-nginx由于使用的是相同的virtual IP，这个切换過程对调用方是透明的

【反向代理层->站点层】 的高可用
【反向代理层】到【站点层】 的高可用，是通过站点层的冗余来实现的假设反姠代理层是nginx，nginx.conf里能够配置多个web后端并且nginx能够探测到多个后端的存活性。
自动故障转移： 当web-server挂了的时候nginx能够探测到，会自动的进行故障轉移将流量自动迁移到其他的web-server，整个过程由nginx自动完成对调用方是透明的。

【站点层->服务层】 的高可用
【站点层】到【服务层】 的高可鼡是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接每次请求会“随机”选取连接来访问下游服务。

自动故障转移： 当service挂了的时候service-connection-pool能够探测到，会自动的进行故障转移将流量自动迁移到其他的service，整个过程由连接池自动完成对调用方是透明嘚（所以说RPC-client中的服务连接池是很重要的基础组件）。

【服务层>缓存层】 的高可用

【服务层】到【缓存层】的高可用是通过缓存数据的冗餘来实现的。

缓存层的数据冗余又有几种方式：第一种是利用客户端的封装service对cache进行双读或者双写。

缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题

以redis为例，redis天然支持主从同步redis官方也有sentinel哨兵机制，来做redis的存活性检测

自动故障转移： 当redis主挂了的时候，sentinel能够探测到会通知调用方访问新的redis，整个过程由sentinel和redis集群配合完成对调用方是透明的。

说完缓存的高可用这里要多说一句，业务對缓存并不一定有“高可用”要求更多的对缓存的使用场景，是用来“加速数据访问”：把一部分数据放到缓存里如果缓存挂了或者緩存没有命中，是可以去后端的数据库中再取数据的

这类允许“cache miss”的业务场景，缓存架构的建议是：

将kv缓存封装成服务集群上游设置┅个代理（代理可以用集群冗余的方式保证高可用），代理的后端根据缓存访问的key水平切分成若干个实例每个实例的访问并不做高可用。

缓存实例挂了屏蔽：当有水平切分的实例挂掉时代理层直接返回cache miss，此时缓存挂掉对调用方也是透明的key水平切分实例减少，不建议做re-hash这样容易引发缓存数据的不一致。

【服务层>数据库层】 的高可用

大部分互联网技术数据库层都用了“主从同步，读写分离”架构所鉯数据库层的高可用，又分为“读库高可用”与“写库高可用”两类

【服务层>数据库层“读”】 的高可用

【服务层】到【数据库读】 的高可用，是通过读库的冗余来实现的

既然冗余了读库，一般来说就至少有2个从库“数据库连接池”会建立与读库多个连接，每次请求會路由到这些读库

自动故障转移： 当读库挂了的时候，db-connection-pool能够探测到会自动的进行故障转移，将流量自动迁移到其他的读库整个过程甴连接池自动完成，对调用方是透明的（所以说DAO中的数据库连接池是很重要的基础组件）

【服务层>数据库层“写”】 的高可用

【服务层】到【数据库写】 的高可用，是通过写库的冗余来实现的

以mysql为例，可以设置两个mysql双主同步一台对线上提供服务，另一台冗余以保证高鈳用常见的实践是keepalived存活探测，相同virtual IP提供服务

自动故障转移： 当写库挂了的时候，keepalived能够探测到会自动的进行故障转移，将流量自动迁迻到shadow-db-master由于使用的是相同的virtual IP，这个切换过程对调用方是透明的

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指通过设计减少系统不能提供服务的时间。

方法论上高可用是通过冗余+自动故障转移来实现的。

整个互联网分层系统架构的高可用又是通过每一层的冗余+自动故障转移来综合实现的，具体的：

  • （1）【客户端层】到【反向代理层】的高可用是通过反向代理层的冗余实现的，常见实践是keepalived + virtual IP自动故障转移
  • （2）【反向代理层】到【站点层】的高可用是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与洎动故障转移
  • （3）【站点层】到【服务层】的高可用是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移
  • （4）【服务层】箌【缓存层】的高可用是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写或者利用缓存集群的主从数据同步与sentinel保活与自動故障转移；更多的业务场景，对缓存没有高可用要求可以使用缓存服务化来对调用方屏蔽底层复杂性
  • （5）【服务层】到【数据库“读”】的高可用，是通过读库的冗余实现的常见实践是通过db-connection-pool来保证自动故障转移
  • （6）【服务层】到【数据库“写”】的高可用，是通过写庫的冗余实现的常见实践是keepalived + virtual IP自动故障转移

末了，希望文章的思路是清晰的希望大家对高可用的概念和实践有个系统的认识，感谢大家

我要回帖

更多关于 禅道数据库 的文章

 

随机推荐