深刻讨论为什么要读写分离?
为了服务器承载更多的用户?提升了网站的响应速度?分摊数据库服务器的压力?就是为了双机热备又不想浪费备份服务器?上面这些回答,我认为都不是错误的,但也都不是完全正确的。「读写分离」并不是多么神奇的东西,也带不来多么大的性能提升,也许更多的作用的就是数据安全的备份吧。
从一个库到读写分离,从理论上对服务器压力来说是会带来一倍的性能提升,但你仔细思考一下,你的应用服务器真的很需要这一倍的提升么?那倒不如你去试着在服务器使用一下缓存系统,如 Memcached、Redis 这些分布式缓存,那性能可能是几十倍的提升。而且,在服务器硬件异常强悍及性能廉价的今天,完全更没必要了,所以,在今天,我认为它更多的职责就是为了数据安全而设计的,同时又提升了一些性能,这样也挺好。
可能我们更应该称之为主从分离。
利用 AOP 实现读写分离
读写分离方式很简单,就是在你读数据是去连接从库,在你写数据的时候去连接主库,具体代码实现当然就是连接时候去操作了,这没什么难度,在代码里写就是了。可是,有追求的程序猿都是不是这么解决问题的呢!
其实通过上篇的 Spring AOP 拦截器的基本实现 我们知道 AOP 可以实现在方法开始执行前后插入执行我们想要的代码,那这样,我们是不是可以在执行数据库操作前根据业务来动态切换数据源呢?
思考一下这个方式理论上好像是可行的,这种方式首先不需要在业务代码中去做切换,二是可能以后我们不需要读写分离了,把 AOP 切换的代码去掉就行了,三是可能就是拓展性好了。
等不了了,开始撸代码
你可能想深入的了解的话,我这里给你几个程序里用到的关键字enum(枚举)、annotation(自定义注解)、JoinPoint(注入点)、AbstractRoutingDataSource(数据源接口子类),你理解了这些就知道了,其实你并不需要深入某些深层的东西,了解下即可。
一、建立JdbcContextHolder.java类
public class JdbcContextHolder { private static final ThreadLocal<String> contextHolder = new ThreadLocal<String>(); public static void setJdbcType(String jdbcType) { contextHolder.set(jdbcType); } public static void setSlave() { setJdbcType("slave"); } public static void setMaster() { clearJdbcType(); } public static String getJdbcType() { return (String) contextHolder.get(); } public static void clearJdbcType() { contextHolder.remove(); } }
这个类的作用就是用来设置、获取数据源连接
二、新建DynamicDataSource.java类,继承于AbstractRoutingDataSource
import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource; import cn.mayongfa.common.JdbcContextHolder; public class DynamicDataSource extends AbstractRoutingDataSource { @Override protected Object determineCurrentLookupKey() { // 获取当前数据源连接 return JdbcContextHolder.getJdbcType(); } }
通过研究,我们知道determineCurrentLookupKey方法是获取相关数据源连接的,所以重写determineCurrentLookupKey方法就可以啦,然后我们去通过刚刚我们建立的JdbcContextHolder类去获取。那怎么设置呢?
三、建立数据源DataSourceType.java枚举类
public enum DataSourceType { //主库 Master("master"), //从库 Slave("slave"); private DataSourceType(String name) { this.name = name; } private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } }
这个枚举类的作用其实就是为了设置数据源而生的,它的目的就是让设置数据源时更方便,如丝般顺滑。
四、新建DataSource.java Annotation(自定义注解)类
import java.lang.annotation.Documented; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) @Documented public @interface DataSource { DataSourceType value() default DataSourceType.Master; }
自定义注解的意义不再过多讨论,一句话来说就是可以让你在类或方法名上以打标签的形式让该方法变得不一样。具体怎么「不一样」,这个在于你。
五、新建DataSourceChoose.java数据库切换类
import java.lang.reflect.Method; import org.aspectj.lang.JoinPoint; import org.aspectj.lang.reflect.MethodSignature; import cn.mayongfa.common.JdbcContextHolder; public class DataSourceChoose { //方法执行前 public void before(JoinPoint point){ Object target = point.getTarget(); String method = point.getSignature().getName(); Class<?>[] classz = target.getClass().getInterfaces(); MethodSignature methodSignature = (MethodSignature)point.getSignature(); Class<?>[] parameterTypes = methodSignature.getMethod().getParameterTypes(); try { Method m = classz[0].getMethod(method, parameterTypes); if (m!=null && m.isAnnotationPresent(DataSource.class)) { DataSource data = m.getAnnotation(DataSource.class); JdbcContextHolder.clearJdbcType(); JdbcContextHolder.setJdbcType(data.value().getName()); } } catch (Exception e) { // TODO: handle exception } } }
这个其实是一个拦截器类,主要作用就是拦截那些方法名上有@DataSource这个自定义注解的,完了根据获取注解的value()值,来做相应的数据源切换。
到这里,整个读写分离的分析及业务逻辑和具体代码都完了,以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
本文向大家介绍mongoDB 实现主从读写分离实现的实例代码,包括了mongoDB 实现主从读写分离实现的实例代码的使用技巧和注意事项,需要的朋友参考一下 mongoDB主从读写分离 MongoDB官方已经不建议使用主从模式了,替代方案是采用副本集的模式, 点击查看。如果您的环境不符合副本集模式可参考本文,来实现主从读写分离。 resources.properties mongo_config.x
本文向大家介绍MySQL 读写分离实例详解,包括了MySQL 读写分离实例详解的使用技巧和注意事项,需要的朋友参考一下 MySQL 读写分离 MySQL读写分离又一好办法 使用 com.mysql.jdbc.ReplicationDriver 在用过Amoeba 和 Cobar,还有dbware 等读写分离组件后,今天我的一个好朋友跟我讲,MySQL自身的也是可以读写分离的,因为他们提供了一个新的
本文向大家介绍Mybatis注解实现多数据源读写分离详解,包括了Mybatis注解实现多数据源读写分离详解的使用技巧和注意事项,需要的朋友参考一下 首先需要建立两个库进行测试,我这里使用的是master_test和slave_test两个库,两张库都有一张同样的表(偷懒,喜喜),表结构 表名 t_user | 字段名 | 类型 | 备注 | | :------: | :------: | :---
当配置好MySQL主从复制后,由于数据复制是单向的,所有对数据库的更新操作都必须在主服务器上进行,只有在主库上更新,才能避免用户对主服务器上数据库内容的更新与对从服务器上数据库内容的更新一致,而不会发生冲突。 MySQL复制环境用户授权方案 生产授权方案1 方案1、2对比推荐使用方案1,生产环境中推荐使用忽略授权表方式授权 数据库 用户名 密码 IP地址 端口 权限 主库 web passwd 1
本文向大家介绍详解使用spring aop实现业务层mysql 读写分离,包括了详解使用spring aop实现业务层mysql 读写分离的使用技巧和注意事项,需要的朋友参考一下 spring aop , mysql 主从配置 实现读写分离,接下来把自己的配置过程,以及遇到的问题记录下来,方便下次操作,也希望给一些朋友带来帮助。 1.使用spring aop 拦截机制现数据源的动态选取。 3.利用
是Jedis这种客户端连接了哨兵后,得到了主从节点缓存到本地,发起命令之前解析命令是读or写,然后请求具体的节点? 还是sentinel统一解析了命令,再做转发?这个过程有负载均衡吗? 网上大多资料介绍读写分离,大多都只是在说主从复制的事,并没有讲解读写分离的过程。 我怎么就知道这个命令是发到从节点执行了呢?