mybatis增强(qilu-mybatis)介绍

senvon大约 13 分钟

mybatis增强(qilu-mybatis)介绍

在开源领域已经存在pageHelper,mybatis-plus的情况下,为啥还要开发qilu-mybatis????

主要是我有偏见,我们认为在pageHelper和mybatis-plus之外,还有一种更好用的mybatis的使用方式.这种方式在于在mybatis-generator-tool自动生成的各种操作太好用了,以至于我认为可以抛弃pageHelper和mybatis-plus带来的便利,而一定要集成mybatis-generator的生成类的方式来使用mybatis.

qilu-mybaits主要特性

支持不同数据库
- 特别是常见的分页,主键策略都存在很大的差异
mybatis-generator的集成
- mybatis-generator是一个很强大的代码生成器,特别是中间的Mapper和配置文件的生成,使用比较爽,爽到需要替换pageHelper或者mybatis-plus

代码集成

qilu-mybatis的maven依赖

<dependency>
	<groupId>com.9istock.base</groupId>
	<artifactId>qilu-mybatis</artifactId>
	<version>最新版本</version>
</dependency>

qilu-generator的maven依赖

<dependency>
	<groupId>com.9istock.base</groupId>
	<artifactId>qilu-generator</artifactId>
	<version>最新版本</version>
	<scope>test</scope>
</dependency>

使用

spring配置

在spring的配置文件中增加mybatis的扫描和qilu-mybatis的bean

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
	<property name="basePackage" value="com.istock.union.user.dao" />
	<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"></property>
</bean>

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
	<property name="dataSource" ref="dataSource" />
	<!-- 自动扫描mapping.xml文件 -->
	<property name="mapperLocations" value="classpath:unionUser/**/*.xml"></property>
	<property name="plugins">
		<list>
			<ref bean="pageInterceptor"/>
		</list>
	</property>
</bean>
<!--拦截器的注入-->
<bean id="pageInterceptor" class="com.istock.base.mybatis.interceptor.PageInterceptor">
	<property name="commonExecutor" ref="commonExecutor">
	</property>
</bean>

<bean id="commonExecutor" class="com.istock.base.mybatis.executor.CommonExecutor">
	<!-- 可以不指定,常见的数据库可以自动识别,包含MYSQL,MSSQL,DB2,ORACLE -->
	<!-- <property name="dialect">
		<bean class="com.istock.base.mybatis.dialect.MysqlDialect"></bean>
	</property> -->
	<!--主键生成策略-->
	<property name="keyType" value="MEM18"/>
	<!--不同的表可以使用不同的组件策略-->
	<!-- <property name="tableMap">
		<map>
			<entry key="AUTH_AUDIT_LOG">
				<value>SEQ</value>
			</entry>
			<entry key="TEST_SENVON_INFO">
				<value>MEM</value>
			</entry>
		</map>
	</property> -->
</bean>

<!--组件策略注入-->
<bean name="strategyService" class="com.istock.base.mybatis.strategy.StrategyService" factory-method="getInstance">
	<property name="strategySet">
		<set>
			<!--依赖数据库的sequence策略生成主键,支持Oracle,DB2,SqlServer-->
			<bean class="com.istock.base.mybatis.strategy.SequenceIdStrategy">
				<property name="dataSource" ref="dataSource"></property>
				<property name="sequenceNumber" value="30"></property>
			</bean>
			<!--基于snowflake的内存模式下的主键生成,支持所有数据库-->
			<bean class="com.istock.base.mybatis.strategy.SnowFlackStrategy">
			</bean>
		</set>
	</property>
</bean>

在CommonExecutor中,我们可以配置不同的数据库方言,一种支持4种数据库方言

Mysql: com.istock.base.mybatis.dialect.MysqlDialect
Oracle: com.istock.base.mybatis.dialect.OracleDialect
DB2: com.istock.base.mybatis.dialect.DB2Dialect
MSSQL: com.istock.base.mybatis.dialect.MSSqlDialect

如果commonExecutor不配置数据库方言,系统就会在启动的时候默认使用数据库产品进行设置

在commonExecutor中,可以配置不同的表使用不同的主键策略,主键策略有二种类型

MEM:使用内存生成主键(推荐使用)
MEM18:使用内存生成18位数字(传统的snowflake有时候会生成19位数字)(推荐使用)
SEQ:使用数据库的sequence功能生成主键

StrategyService,是主键策略的自定义,可以支持二次开发,需要实现com.istock.base.mybatis.strategy.IdStrategy接口

在使用qilu-mybatis进行batch,insert操作时,为了减少数据库的访问会生成批量的获取id,在这种模式下,无法支持自增长主键的生成.

在使用修改后的qilu-generator的基础上,正常生成mapper和pojo类

( select ID, NAME, AGE, CREATE_YEAR from TEST_MODEL_TABLE_2021 WHERE ( NAME like ? ) ) union all ( select ID, NAME, AGE, CREATE_YEAR from TEST_MODEL_TABLE_2020 WHERE ( NAME like ? ) ) order by CREATE_YEAR DESC limit 0,2

非常规数据库操作

事务不生效的排查

检查spring配置文件,是否有<tx:annotation-driven />的配置
扫描参与事务的类的时候,需要使用listener的方式加载,不能使用dispatcher-servlet的方式加载.这是2种不同的spring的配置加载方式,会出现相互覆盖的情形,一般配置dispatcher-serlvet不扫描service类,只扫描controller类.
检查抛出的异常,spring只会对runtimeException的异常做回滚处理,一般的Exception没有特殊声明,不会回滚
方法内部的调用,不会触发事务控制.一个类里面,有没有事务的methodA方法,调用有事务的methodB方法,methodB上的事务,不会生效.spring的事务是使用拦截器实现的,在实现拦截器是使用动态代理实现的,一个类的内部调用,不会触发动态代理.

方法内部的事务控制

常见推荐的事务操作,是在方法上,增加@Transactional的注解,这种级别的注解可以有效解决80%以上的业务问题,而且很方便.但是针对有些业务场景,正常的事务需要细化到方法内部,手动控制事务的提交和回滚.

@Autowired
private TransactionTemplate template;
@Autowired
private OrgUserDAO orgUserDao;

public OrgUser updateOrg(final String key){
	//do something not in the transaction
	return template.execute(new TransactionCallback<OrgUser>(){

		@Override
		public OrgUser doInTransaction(TransactionStatus status) {
			try{
				OrgUser user = new OrgUser();
				user.setId(key);
				user.setUserName("senvonTest");
				orgUserDao.updateByPrimaryKeySelective(user);
				return orgUserDao.selectByPrimaryKey(key);
			}catch(Exception e){
				status.setRollbackOnly();
				e.printStackTrace();
			}
			return null;
		}
	});
	//do something not in the transaction
}

直接使用DataSource

Spring管理了所有的数据源,在大部分的业务场景里面,数据源对于应用系统来说,是一个相对静态的资源.在部分业务场景里面,数据源是一个动态的资源,在部署配置的时候,无法将数据源配置到系统里面在spring的管理的数据源下面,不允许出现手动DataSource.getConnection()的操作,也不允许出现conn.close()操作,手动操作数据源,会引发数据源的衰竭,一个被关闭的数据源,spring没有保证一定是连接状态,在应用程序申请数据源的过程中,如果没有控制好,就会出现数据源返回一个已经关闭的连接,造成系统各种异常如果出现这种情形,请使用spring提供的JdbcTemplate或者NamedParameterJdbcTemplate来实现数据库操作.

//直接注入数据源
@Autowired
private DataSource dataSource;

public List<OrgUser> findUser(String name){
	String sql = "SELECT * FROM TB_ORG_USER WHERE USER_NAME LIKE :userName";
	//使用JDBCTemplate操作数据源
	NamedParameterJdbcTemplate template = new NamedParameterJdbcTemplate(dataSource);
	Map<String , Object> paramMap = new HashMap<String , Object>();
	paramMap.put("userName", name);
	return template.query(sql, paramMap, new RowMapper<OrgUser>() {
		@Override
		public OrgUser mapRow(ResultSet rs, int rowNum) throws SQLException {
			OrgUser user = new OrgUser();
			user.setDeptCode(rs.getString("DEPT_CODE"));
			user.setId(rs.getString("ID"));
			user.setIdCode(rs.getString("ID_CODE"));
			user.setPassword(rs.getString("PASSWORD"));
			user.setRemark(rs.getString("REMARK"));
			return user;
		}
	});
}

替代存储过程

无论是数据库上的function,procedure还是job,理论上都是属于数据库工具,开发人员不应该触碰这类工具

数据库工具最大的好处是直接在数据库上操作,避免大的数据量的交互.但是会占据数据库的CPU,而数据库的CPU在整个系统群里面,是最珍贵的,没有之一.

比如有这么一个场景,日终给活期账户计算利息.

一个很简单的操作,会因为活期账户的数量成为难题,如果活期账户在1W以内,随便操作. 但是如果活期账户数量达到100W+,事情就会变得难办.要计算利息,必须先把记录从数据库中加载到内存,再计算.

所以,为了避免大量数据的操作,就会考虑使用游标,这个也就是一般活期计算利息使用存储过程的一个原因.

下面这种处理方式,既能解决数据量大的问题,又能解决性能的问题

@Autowired
private DataSource dataSource;
public void test(){
	String sql = "SELECT * FROM TB_ORG_USER";
	JdbcTemplate template = new JdbcTemplate();
	template.query(sql, new ResultSetExtractor<Object>(){
		@Override
		public Object extractData(ResultSet rs) throws SQLException,DataAccessException {
			//设置resultSet获取数据的缓存
			rs.setFetchSize(10000);
			List<OrgUser> userList = new ArrayList<OrgUser>();
			while(rs.next()){
				OrgUser user = new OrgUser();
				user.setDeptCode(rs.getString("DEPT_CODE"));
				user.setId(rs.getString("ID"));
				user.setIdCode(rs.getString("ID_CODE"));
				user.setPassword(rs.getString("PASSWORD"));
				user.setRemark(rs.getString("REMARK"));
				userList.add(user);
				if(userList.size()>10000){
					//启动线程,执行计算
					// new Thread();
					userList.clear();
				}
			}
			//rs.next退出,userList会有遗留的数据没有处理
			if(userList.size()>10000){
				//启动线程,执行计算
				// new Thread();
				userList.clear();
			}
			return null;
		}
	});
}

解决的原理很简单,JDBC中的ResultSet,在数据库层面的实现就是游标,为了使用游标,而是用存储过程,是一种不明智的选择.更多的应该在应用层面解决这个问题,而不是在数据库. 这种方式,对比存储过程的处理方式,唯一不好的,是会消耗数据库的网络IO,但是可以减少DB上的CPU压力,带来的是应用的大批量的多线程处理,总体来说利大于弊,收益更大.

mybatis增强(qilu-mybatis)介绍

mybatis增强(qilu-mybatis)介绍

代码集成

qilu-mybatis的maven依赖

qilu-generator的maven依赖

使用

spring配置

代码自动生成

生成工具的maven依赖

配置

使用范例

分页查询

top查询

乐观锁更新

批量处理

模板表/分表的操作

自定义SQL

自定义sql使用分页

模板表/分表的联合查询

非常规数据库操作

事务不生效的排查

方法内部的事务控制

直接使用DataSource

替代存储过程