实现构建并发业务系统_第1页
实现构建并发业务系统_第2页
实现构建并发业务系统_第3页
实现构建并发业务系统_第4页
实现构建并发业务系统_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、实现构建并发业务系统1 系统产生并发的业务节点并发产生的原因:(1)短时间大量恳求竞争低速存储设备或者竞争处理器资源。(2)不合理的程序处理逻辑导致恳求无法尽快完成。(3)其他瓶颈,如带宽、效劳器资源等。2 应对并发的解决方案2.1 针对并发量不高的情况的方案分库分表,本质上是分布式系统的一种形式详细逻辑如下:将本来属于同一台效劳器的同一个数据库拆分到多台效劳器中,甚至可以将本来同属于一张表的字段拆分到不同的效劳器上。其目的为将一个大的读写恳求分解到多台效劳器中,从而在异步并行执行中减少恳求执行时间,以到达并发周期中可承载更多的恳求。2.2 使用分布式处理,结合CDN负载平衡技术2.2.1 镜

2、像形式将一台效劳器的镜像副本复制到多台效劳器中, 通过windows的NLB或者第三方CDN方案如nginx实现分布式处理,恳求平衡。此种分布式形式在windows下只能使用NBL,因为NBL仅支持镜像式分布式效劳器集群,理论上NLB可以支持32台效劳器。NLB形式的分布式系统的优势在于通过负载平衡可以充分发挥分布式系统在读数据比较频繁的形式下发挥最大的效益,而且彼此之间互为备份。其缺点也是明显的,因为同一条数据的写入(更新或者删除等写操作)必须通过事务在集群内每台效劳器上同步。2.2.2 分段形式多台效劳器通过CDN来决定数据写入那一台或者多台效劳器中,数据在读取时需要在多台效劳器中轮询,增

3、加了数据读取的复杂度。2.3 使用分布式缓存技术分布式缓存技术已经得到广泛应用,其实现算法为平衡树(红黑树),使用缓存的目的是要减少访问效劳器低速存储设备以及I/O带来的性能损耗,从而进步系统单位时间内的响应才能,以到达进步并发才能的目的。分布式缓存有很多典型应用,例如聊天室。早期的聊天室没有使用socket前,根本上使用的都是脉冲形式(效劳器轮询),不断向低速存储设备轮询的本钱是很可观的。所以写入内存当中可以更快速的使客户端访问到,一旦聊天完毕,效劳器并不持久化聊天数据。投注业务具有短时间集中并发写入数据的特点,将数据写入内存,并在内存中操作并非复杂的事情。但如涉及到数据持久化,就存在数据一

4、致性的问题。分布式缓存解决方案redis提供了数据持久化,可以保证数据的一致性。理论证明,10万级别的并发场景中,向低速存储设备(关系数据库)写入数据假设以整形为主,使用缓存和不使用缓存的差异并不明显。2.4 NOSQL的使用NOSQL 数据库的数据吞吐才能可以到达关系数据库的百倍以上,天然支持分布式形式。可以提供高速读写的优异性能,提供高I/O操作。谷歌、百度、淘宝等都使用了NOSQL。但NOSQL也并非没有缺点,大多数应用都是关系型的,也就是要保证数据操作的原子性和唯一性,NOSQL无法保证这一点。因此多数NOSQL 应用需要数据库中间件来保证关系数据的原子性。常用的NOSQL 如Mong

5、oDB、Hadoop等。3 并发解决方案的实现分库分表的实现:A:为什么要分库分表?在只有一台效劳器的情况下,大量的select会被同时执行的update和delete阻塞,导致并发数严重受限。当然,这种场景非常适宜读远大于写的应用,当读写根本相当的情况下,单台效劳器照旧存在读写互斥的情况,不适宜并发量较大的应用。B:分库的作用在于多台效劳器分担客户端的读写恳求,大大降低了并发的可能性。在web应用中,通常web效劳器应与数据库效劳别离,这在将来实现CDN的时候非常有意义,来自客户端的恳求根本会在web效劳器之间进展分配,由web效劳器根据CDN决定访问哪些数据库效劳器。数据库效劳器别离后,多

6、台数据库效劳器之间通过异步数据事务保持一致性,当然这种数据同步会有一些时间上的延迟,这种延迟根本上都是毫秒级别的。当然,低级别的分库可以直接由逻辑层通过事务保证数据一致性。操作系统对磁盘的读写有控制机制,在只有一台效劳器的情况下,各种恳求竞争资源,包括对处理机及内存、磁盘等的控制权。因此,一台效劳器的并发才能是非常有限的,这也是分库的原因所在。3.1 关于读写别离前文已提到读写互斥,这将给读取数据带来很大延迟,尤其是大量读写的情况下这种延迟是无法承受的。因此在读业务场景中,应保持数据随时处于可读取状态。通过分库、分表以到达读写别离的目的,让一些(库)表专门用来写数据,而另一些表(库)用来读数据

7、。而数据库与数据库之间通过数据一致性组件保持数据复制作业,如sync Navigator 或者数据库自带的订阅发布功能。用于写操作的数据库一旦有新数据写入,那么根据数据同步策略来同步数据到读效劳器(数据库、表)中。3.2 关于缓存Memcached 是一个高性能的分布式内存对象缓存系统,用于动态Web 应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数,从而提供动态、数据库驱动网站的速度。memcache 会预先生成很多的内存块,比方有96byte,120byte,150byte,200byte,800byte。预先生成一批slab的好处是什么?可以根据item的大小,放

8、到适宜的slab上面去。原因:找内存所消耗的时间比远大于释放时间。但是Memcached对内存资源的有效利用:(1)重复利用已经分配的内存,也就是说不会去删除已有的数据而且释放,而是数据过期后,用户将数据不可见。(2)Memcached还是用了一种LazyExpiration(延迟过期姑且这样翻译)技术,就是Memcached不会去监视效劳器上的数据是否过期,而是等待get的时候检查时间戳是否过期,减少Memcached在监控数据上所用到的时间。(3) Memcached不会去释放已经使用的内存空间,但是假设分配的内存空间已经满了,而Memcached是如何去保证内存空间的重复使用呢! Mem

9、cached是用了 Least RecentlyUsed(LRU)机制来协调内存空间的使用。LRU意思就是最少最近使用,当此处内存空间数据最长时间没有使用,而且使用次数很少,在存储新的数据的同时就会覆盖此处空间。一致性哈希当hash 遇上分布式,单台机子的hashmap存储已经不能满足我们的key-value需求,怎么办,我们需要把存储内容分布到不同的实体机上,这时需要一种把key 映射到不同机器的方法,我们想起了hash,可以把实体机当作是桶,采用和hashmap实现一样的思路,通过和实体机的数量取模,自然映射到不同的机器。但是这就会导致一个问题:数据分布不均匀。大部分数据都分配到serve

10、r1了,只有小部分数据分布在server2。在效劳器数据很少的时候,数据不均 匀会表现的非常明显。解决这个问题的方法是使用虚拟节点,一个真实效劳器对应多个虚拟节点,所有虚拟节点按hash值分布在一致性哈希圆环上。详细实现方法可以这样做,为真实效劳器设置副本数量,然后根据各真实效劳器的IP和端口号再加上一个递增的索引数计算hash值。分布式缓存可以解决以下几种问题:比方用来缓存Web页面的内容片段,包括HTML、CSS和图片等,多应用于社交网站等;应用对象缓存:缓存系统作为ORM框架的二级缓存对外提供效劳,目的是减轻数据库的负载压力,加速应用访问;状态缓存:缓存包括Session会话状态及应用横

11、向扩展时的状态数据等, 这类数据一般是难以恢复的,对可用性要求较高, 多应用于高可用集群;并行处理:通常涉及大量中间计算结果需要共享;事件处理:分布式缓存提供了针对事件流的连续查询(continuous query)处理技术, 满足实时性需求;极限事务处理:分布式缓存为事务型应用提供高吞吐率、低延时的解决方案,支持高并发事务恳求处理, 多应用于铁路、金融效劳和电信等领域。3.3 关于NOSQL以SQL SERVER2021作为数据仓库存储逻辑数据,当关系型数据库无法满足并发要求的时候,后端增加使用非关系型数据库mongodb作为高吞吐数据库使用,为防止NOSQL数据库的非原子性操作带来的一些问

12、题,架构使用SQL SERVER作为数据一致性中间件,以分布式缓存作为业务快速存储载体,进步整个系统的并发响应才能。MongoDB一个文件存储片段最大2GB,所以随着数量的增加,MongoDB会一个又一个增加数据存储文件,正因为是多个文件,所以可以并行从多个文件中读取和写入数据,但是因为是多个文件的并行处理,带来了高IO,也带来了致命的缺陷,原因非常明显,那就是关系数据库为了保证数据的一致性,使用了原子性约束,也就是我们说的原子性操作,比方添加数据库记录时,不允许出现两条数据完全一样,比方主键都是2,这样的话就没方法唯一标识这条数据了,所以关系数据库普遍采用了原子性(唯一性)约束,非关系数据库和关系数据库在这一点上的区别非常鲜明,那就是无法保证原子性操作,非关系数据库不保证原子性,也就无法保证数据的唯一性,这样在连表查询时就无法获取正确的数据,所以一般情况下都是由中间件或者关系数据库来保证数据的唯一性,比方NOSQL数据库专门用来读操作,你不是I/O才能很强吗(是关系数据库的100倍),那你就专门用来读,数据通过各种手段先写

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论