Oracle之垂直水平分库分表（二）

对于拆分的解决方案这块,上节课我们讲到了如何去拆分,然后拆分有些问题,引入了一系列的问题,比如说分布式事务的问题,关于分布式事务这个事啊,其实挺不好解决的,就是根据情况吧,咱们在这里说三个方案,你针对不同的场景去分析,然后你说业务逻辑很复杂的时候,你就采用SOA通用服务的形式,在service上加多个事务的切面,就可以去解决第二种情况就比如数据量非常大的时候,数据量大且逻辑复杂的时候,就是不仅仅是逻辑复杂了,并且数据量也很大,那你那个时候使用SOA服务,就不太好了,因为有个问题,早期的时候没有SOA的这种dubbo,你可能就是一次http请求呗,其实就是类似于http请求的,你去访问一个数据源的时候,你比如你一次dubbo请求,这是咱们的WEB程序,然后你要访问对应的SOA服务,SOA端,访问这里边的某一个方法,你说你这个业务复杂没什么,因为JAVA很快,但是如果你要是数据量大的时候,比如我这里request的信息非常多,就是几十条,上百条,然后这边肯定得处理啊,那这个过程就很慢了,再给你做出响应,你这个时候业务复杂并且数据量大的时候,不适合这个东西的,那应该采用什么方案呢,就是不用这个SOA了,我就采用中间库的解决方案,就类似于两个系统之间,我这个系统可以同步到数据库上,他们两个可以当做什么也没有发生,如果我说的那种情况,定时可以把数据放到库里,这个系统再定时的去这个库里去取数据,这样就很大了,能不能说只要关心自己的业务就行了,其实还有一种方案就是,这是一个系统,这是一个系统,我这边就是我中间的数据库,这边有一个数据源数据库,这是我们的系统B,这是我们的系统A,我自己也可以写一个应用服务,这个worker服务是用来调度的,他主要是负责放在这里面,并且是负责把数据挖取出来,然后再放到这里,其实都可以,如果你性能不是要求这么高的话,数据量很大,实时性要求不是那么高的话,你可以用一个worker去做,去做这个协调,或者这里提供一个定时JOB,这里也提供一个定时JOB,这都行,就是类似于跨库的物化视图,也可以去做实时的更新,还有一种其他的,要求实时性非常高的怎么办,你要求实时性非常高了,那你就得去写第三方的中间件,依赖于第三方组件,zookeeper,或者你自己写一个,或者是用这个netty,两个系统直接通信,或者你要求非常实时,要求很实时,这几种方案都不行,那你只能是rest服务了,提供接口,我这边去调,前提是数据量一定别太大,第三种方案就是数据量别太大,数据量大的话还是要用中间件导一下是分布式怎么去解决

然后下面是跨节点join的问题,是一些合并啊,排序啊,分页啊,这些东西怎么办,通用的方案是把数据组织好,放到缓存中,关系型数据库和缓存定时的去同步,然后你要求不是特别高的话,可以使用中间库去解决,我们工作中就是用中间库去解决跨节点join的问题,举个例子,比如说这里有一个系统,里边有一张表,然后我中间有一个数据库,这里是A库,这里是B库,然后这里是C什么库,我这里建一个物化视图,咱们之前刚学,物化视图把这里的数据同步过来,把这里的数据同步过来,只要两边有commit,我这边物化视图就刷新,由于物化视图真正存在物理结构里,你如果并发太高的话,肯定扛不住,高不高怎么说呢,这个取决于什么呢,我觉得我们现在用的还可以,其实没有什么大的问题,并发高的话就相当高了,几万次这个并发就比较高了,那就不太适合了,并发高的意思就是,这边B系统一万个用户,10万个用户,10万个用户去修改这张表,并发高,这边肯定需要实时的刷新,把心刷新的数据存在物理的磁盘里,包括这边也再来多点,来个10万个,就特别频繁特别频繁的,只要一commit,我这个物化视图就得更新,并发不是特别高的情况下,数据量大,并发不是很高,所以你可以用物化视图解决方案,ON COMMIT或者是 ON DEMAND,每一小时我就同步一下,每隔一小时我就刷一次,就是每隔一分钟刷一次也可以,或者每隔一秒钟你就刷一次,这都行,就是别一秒钟数十万的并发,ORACLE肯定是扛不住的,或者你用一些其他的工具,同步的工具,那个性能应该是可以的,应该是可以的,数据源管理的问题,我这个数据源一多,我这里怎么去管理呢,可以去使用第三方的MYCAT,目前并不是很成熟,以后咱们可以考虑去使用,或者是你是正常的,一个模块你管理自己的数据源,这样就可以了,大不了我在zookeeper上写一个配置文件,把所有的数据源都列上来,提供一个公共的用户,访问界面,操作数据源的更新,修改,你要写自己的一个小系统了,去维护这个数据源,也是可以的,这就是解决方案简单的说一下,今天主要是讲分区,

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！