如何设计软件系统框架结构,功能模块,和数据库

发布网友

我来回答

2个回答

懂视网

缘起:受@萧田国 萧总邀请,上周五晚上在“高效运维1号群”内分享了《58同城数据库软件架构设计与实践》(这个topic今年在数据库大会上分享过),应组织方要求,发出纪要。


一、基本概念

二、数据库架构设计思路

(1)可用性

(2)读性能

(3)一致性

(4)扩展性


一、基本概念

概念一“单库”

技术分享图片

概念二“分片”

技术分享图片
分片解决的是“数据量太大”的问题,也就是通常说的“水平切分”。

一旦引入分片,势必有“数据路由”的概念,哪个数据访问哪个库。

路由规则通常有3种方法:

(1)范围:range

优点:简单,容易扩展

缺点:各库压力不均(新号段更活跃)

(2)哈希:hash

优点:简单,数据均衡,负载均匀

缺点:迁移麻烦(2库扩3库数据要迁移)

(3)路由服务:router-config-server

优点:灵活性强,业务与路由算法解耦

缺点:每次访问数据库前多一次查询

大部分互联网公司采用的方案二:哈希分库,哈希路由

概念三“分组”

技术分享图片
分组解决“可用性”问题,分组通常通过主从复制的方式实现。

互联网公司数据库实际软件架构是:又分片,又分组(如下图)

技术分享图片


二、数据库架构设计思路

数据库软件架构师平时设计些什么东西呢?至少要考虑以下四点:

(1)如何保证数据可用性

(2)如何提高数据库读性能(大部分应用读多写少,读会先成为瓶颈)

(3)如何保证一致性

(4)如何提高扩展性


2.1如何保证数据的可用性?

解决可用性问题的思路是=>冗余

如何保证站点的可用性?复制站点,冗余站点

如何保证服务的可用性?复制服务,冗余服务

如何保证数据的可用性?复制数据,冗余数据

数据的冗余,会带来一个副作用=>引发一致性问题(先不说一致性问题,先说可用性)

如何保证数据库“读”高可用?

冗余读库

技术分享图片
冗余读库带来的副作用?读写有延时,可能不一致

上面这个图是很多互联网公司mysql的架构,写仍然是单点,不能保证写高可用。

如何保证数据库“写”高可用?

冗余写库

技术分享图片
采用双主互备的方式,可以冗余写库

带来的副作用?双写同步,数据可能冲突(例如“自增id”同步冲突),如何解决同步冲突,有两种常见解决方案:

(1)两个写库使用不同的初始值,相同的步长来增加id:1写库的id为0,2,4,6...;2写库的id为1,3,5,7…

(2)不使用数据的id,业务层自己生成唯一的id,保证数据不冲突

58同城没有使用上述两种架构来做读写的“高可用”,58同城采用的是“双主当主从用”的方式:

技术分享图片
仍是双主,但只有一个主提供服务(读+写),另一个主是“shadow-master”,只用来保证高可用,平时不提供服务。

master挂了,shadow-master顶上(vip漂移,对业务层透明,不需要人工介入)

这种方式的好处:

1)读写没有延时

2)读写高可用

不足:

1)不能通过加从库的方式扩展读性能

2)资源利用率为50%,一台冗余主没有提供服务

那如何提高读性能呢?进入第二个话题,如何提供读性能。


2.2如何扩展读性能?

提高读性能的方式大致有三种,第一种是建立索引。这种方式不展开,要提到的一点是,不同的库可以建立不同的索引。

技术分享图片
写库不建立索引;

线上读库建立线上访问索引,例如uid;

线下读库建立线下访问索引,例如time;

第二种扩充读性能的方式是,增加从库,这种方法大家用的比较多,但是,存在两个缺点:

(1)从库越多,同步越慢

(2)同步越慢,数据不一致窗口越大(不一致后面说,还是先说读性能的提高)

58同城没有采用这种方法提高数据库读性能(没有从库),采用的是增加缓存。常见的缓存架构如下:

技术分享图片
上游是业务应用,下游是主库,从库(读写分离),缓存。

58同城的玩法是:服务+数据库+缓存一套

技术分享图片
业务层不直接面向db和cache,服务层屏蔽了底层db、cache的复杂性。为什么要引入服务层,今天不展开,58采用了“服务+数据库+缓存一套”的方式提供数据访问,用cache提高读性能。

不管采用主从的方式扩展读性能,还是缓存的方式扩展读性能,数据都要复制多份(主+从,db+cache),一定会引发一致性问题。


2.3如何保证一致性?

主从数据库的一致性,通常有两种解决方案:

(1)中间件

技术分享图片
如果某一个key有写操作,在不一致时间窗口内,中间件会将这个key的读操作也路由到主库上。

这个方案的缺点是,数据库中间件的门槛较高(百度,腾讯,阿里,360等一些公司有,当然58也有)

(2)强制读主

技术分享图片
58的“双主当主从用”的架构,不存在主从不一致的问题。

第二类不一致,是db与缓存间的不一致

技术分享图片
常见的缓存架构如上,此时写操作的顺序是:

(1)淘汰cache

(2)写数据库

读操作的顺序是:

(1)读cache,如果cache hit则返回

(2)如果cache miss,则读从库

(3)读从库后,将数据放回cache

在一些异常时序情况下,有可能从【从库读到旧数据(同步还没有完成),旧数据入cache后】,数据会长期不一致。

解决办法是“缓存双淘汰”,写操作时序升级为:

(1)淘汰cache

(2)写数据库

(3)在经验“主从同步延时窗口时间”后,再次发起一个异步淘汰cache的请求

这样,即使有脏数据如cache,一个小的时间窗口之后,脏数据还是会被淘汰。带来的代价是,多引入一次读miss(成本可以忽略)。

除此之外,58同城的最佳实践之一是:建议为所有cache中的item设置一个超时时间。

说完一致性,最后一个话题是扩展性。


2.4如何提高数据库的扩展性?

原来用hash的方式路由,分为2个库,数据量还是太大,要分为3个库,势必需要进行数据迁移,58同城有一个很帅气的“数据库秒级扩容”方案。

如何秒级扩容?

首先,我们不做2库变3库的扩容,我们做2库变4库(库加倍)的扩容(未来4->8->16)

技术分享图片

服务+数据库是一套(省去了缓存)

数据库采用“双主”的模式。

扩容步骤:

第一步,将一个主库提升

第二步,修改配置,2库变4库(原来MOD2,现在配置修改后MOD4)

扩容完成

技术分享图片

原MOD2为偶的部分,现在会MOD4余0或者2

原MOD2为奇的部分,现在会MOD4余1或者3

数据不需要迁移,同时,双主互相同步,一遍是余0,一边余2,两边数据同步也不会冲突,秒级完成扩容!

最后,要做一些收尾工作:

(1)将旧的双主同步解除

(2)增加新的双主(双主是保证可用性的,shadow-master平时不提供服务)

(3)删除多余的数据(余0的主,可以将余2的数据删除掉)

技术分享图片
这样,秒级别内,我们就完成了2库变4库的扩展。


OK,今天主要分享了58同城,数据库软件架构上:

(1)如何保证数据可用性

(2)如何提高数据库读性能

(3)如何保证数据一致性

(4)如何进行秒级扩容

希望大家有收获,谢谢大家!

===【完】===

 

【转自】58沈剑 架构师之路

【转载】数据库软件架构设计些什么

标签:个数   mda   设计   time   ott   item   logs   ##   key   

热心网友

摘要数据结构 数据结构指的是数据之间的相互关系,即数据的组织形式。数据结构是计算机存储、组织数据的 方式。数据结构是指相互之间存在一 种或多种特定关系的数据元素的集合 。通常情况下,精心选择的数据结构 可以带来更高的运行或者存储效率。 数据结构往往同高效的检索算法和索 引技术有关。 我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。 在数据模型设计中有一个重要概念:持久数据操作,它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。 在很多软件系统中,数据是其核心,因此,对数据元素的格式、结构、访存、表示等机制进行良好建模和优化,是提高软件设计质量和系统性能的基础,对软件系统的应用具有重要意义。 面向组件设计 面向组件思想是在软件规模扩大,复杂度上升的背景下,以面向对象为基础而提出的一种软件设计思想。可以把它理解为一种更粗粒度的面向对象,其粒度一般大于对象,但具体要到什么程度,又可以根据实际情况来决定。这种思想以组件为基础,强调“服务”的概念。 在面向组件开发中,应用程序是由一系列可以互相交互的二进制模块组合而成的。 一个具体的二进制组件可能并不能完成什么工作。有些组件是为了提供一些常规服务而编写的,例如通信的封装或者文件访问组件。也有一些是为了某些特定应用而专门开发的。一个应用程序的设计者可以通过把这些不同的组件提供的功能粘合在一起来实现他们需要的商业逻辑。很多面向组件的技术——例如: COM 、 J2EE 、 CORBA 和 .NET 都为二进制组件提供了的无缝链接的机制。而唯一的不同就是你需要在组件通信上花费的力气。一般的多用于对dll,lib的处理上。 简单说,就是QQ、迅雷和IE*起来就叫面向组件。 面向组件具有以下特点:低耦合性,高重用性,高互操作性,进程的透明性,语言和开发环境的性 软件体系结构风格 软件体系结构风格是软件设计人员在长期的软件设计过程中总结出来的一些规律性的东西,经过提炼总结而成。软件体系结构风格是软件体系结构设计上的模式,因此可以看作是一种广义的软件设计模式,但一般不认为是侠义的软件设计模式。 定义:在构件和连接子的层次描述的可重复使用的软件设计问题解决方案。 管道/过滤器风格:一个显著特征是:系统中构件之间通过数据流松散耦合。也就是说,构件之间的依赖仅仅是数据流,而不是通常的接口咨询记录 · 回答于2021-10-20如何设计软件系统框架结构,功能模块,和数据库数据结构 数据结构指的是数据之间的相互关系,即数据的组织形式。数据结构是计算机存储、组织数据的 方式。数据结构是指相互之间存在一 种或多种特定关系的数据元素的集合 。通常情况下,精心选择的数据结构 可以带来更高的运行或者存储效率。 数据结构往往同高效的检索算法和索 引技术有关。 我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。 在数据模型设计中有一个重要概念:持久数据操作,它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。 在很多软件系统中,数据是其核心,因此,对数据元素的格式、结构、访存、表示等机制进行良好建模和优化,是提高软件设计质量和系统性能的基础,对软件系统的应用具有重要意义。 面向组件设计 面向组件思想是在软件规模扩大,复杂度上升的背景下,以面向对象为基础而提出的一种软件设计思想。可以把它理解为一种更粗粒度的面向对象,其粒度一般大于对象,但具体要到什么程度,又可以根据实际情况来决定。这种思想以组件为基础,强调“服务”的概念。 在面向组件开发中,应用程序是由一系列可以互相交互的二进制模块组合而成的。 一个具体的二进制组件可能并不能完成什么工作。有些组件是为了提供一些常规服务而编写的,例如通信的封装或者文件访问组件。也有一些是为了某些特定应用而专门开发的。一个应用程序的设计者可以通过把这些不同的组件提供的功能粘合在一起来实现他们需要的商业逻辑。很多面向组件的技术——例如: COM 、 J2EE 、 CORBA 和 .NET 都为二进制组件提供了的无缝链接的机制。而唯一的不同就是你需要在组件通信上花费的力气。一般的多用于对dll,lib的处理上。 简单说,就是QQ、迅雷和IE*起来就叫面向组件。 面向组件具有以下特点:低耦合性,高重用性,高互操作性,进程的透明性,语言和开发环境的性 软件体系结构风格 软件体系结构风格是软件设计人员在长期的软件设计过程中总结出来的一些规律性的东西,经过提炼总结而成。软件体系结构风格是软件体系结构设计上的模式,因此可以看作是一种广义的软件设计模式,但一般不认为是侠义的软件设计模式。 定义:在构件和连接子的层次描述的可重复使用的软件设计问题解决方案。 管道/过滤器风格:一个显著特征是:系统中构件之间通过数据流松散耦合。也就是说,构件之间的依赖仅仅是数据流,而不是通常的接口亲你看看这些觉得本次答题满意给个赞⭐殺殺祝你双十一快乐殺

声明声明:本网页内容为用户发布,旨在传播知识,不代表本网认同其观点,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。E-MAIL:11247931@qq.com