前言
用過mybatis-plus的朋友可能會知道，mybatis-plus提供了多租戶插件的功能，這個功能可以讓開發人員不用手動寫租戶語句，由該插件自動幫你加上租戶語句。今天的素材來源就是取自業務開發人員使用多租戶插件時，遇到的一個神奇的問題
問題重現
業務開發人員要實現根據手機號碼更新租戶的密碼功能，其代碼形如下
for(Tenant t : tenantList){
ApplicationChainContext.getCurrentContext().put(ApplicationChainContext.TENANT_ID,t.getId()+"");
Optional<SaasUser> user = this.findByUserPhone(req.getUserPhone());
user.ifPresent(u -> {
count.getAndSet(count.get() + 1);
LambdaUpdateWrapper<SaasUser> wrapper = new LambdaUpdateWrapper<>();
String md5Pwd = Md5Utils.hash(req.getNewUserPwd());
wrapper.eq(SaasUser::getId,user.get().getId());
wrapper.set(SaasUser::getUserPwd,md5Pwd);
this.update(wrapper);
});
}
從代碼上看起來沒啥問題，因為使用了多租戶插件，當我們執行this.findByUserPhone(req.getUserPhone());就會自動帶上租戶的信息。但在執行的時候發現一個問題，如下圖
從圖中我們可以發現，當查詢不到用戶信息時，后續的查詢操作，都沒有sql語句出現。這說明2點，sql語句要么被系統吃了，要么系統沒有執行sql
問題分析
前面說了sql語句沒有打印出來，說明sql要么沒執行，要么就sql語句被系統吃了。到底是哪種，與其猜測，倒不如去官方找找問題的答案，很遺憾在mybatis-plus官網或者issue上並沒找到答案，於是只好跟蹤源碼進行分析。最后發現mybatis-plus果然如他官網介紹的只做增強不做改變，他最終調用查詢的邏輯，走的是原生mybatis的查詢邏輯。其查詢的核心代碼如下
public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId());
if (this.closed) {
throw new ExecutorException("Executor was closed.");
} else {
if (this.queryStack == 0 && ms.isFlushCacheRequired()) {
this.clearLocalCache();
}
List list;
try {
++this.queryStack;
list = resultHandler == null ? (List)this.localCache.getObject(key) : null;
if (list != null) {
this.handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
} else {
list = this.queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
}
} finally {
--this.queryStack;
}
if (this.queryStack == 0) {
Iterator var8 = this.deferredLoads.iterator();
while(var8.hasNext()) {
BaseExecutor.DeferredLoad deferredLoad = (BaseExecutor.DeferredLoad)var8.next();
deferredLoad.load();
}
this.deferredLoads.clear();
if (this.configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
this.clearLocalCache();
}
}
return list;
}
}
從代碼我們可以得出一個重要的信息，如下
list = resultHandler == null ? (List)this.localCache.getObject(key) : null;
if (list != null) {
this.handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
} else {
list = this.queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
}
當resultHandler為空 ，list的取值是this.localCache.getObject(key)，即會走本地緩存，而不會進行數據庫查詢
問題破解
從源碼可以得知，原生的mybatis默認會走本地緩存，即所謂的一級緩存，而mybatis-plus作為mybatis的增強版，其邏輯和mybatis原生邏輯是一樣的。那如何禁用mybatis-plus的一級緩存呢，從源碼分析，我們可以得知，當list為空時，則不會走緩存，而會查詢數據。而list的緩存取值，來源於
this.localCache.getObject(key)。因此禁用緩存的逆向思維就是要么清空localCache，要么就是變更key，使this.localCache.getObject(key)取到的值為null。因此解決方案至少有以下兩種
方案一：清空localCache
那要怎么清空？
通過源碼我們可以看到清空localCache的地方有兩處，一處是
if (queryStack == 0 && ms.isFlushCacheRequired()) {
clearLocalCache();
}
另外一處是
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
// issue #482
clearLocalCache();
}
因此我們可以通過變更configuration.getLocalCacheScope()為STATEMENT進行清空。可以通過在yml做如下配置
mybatis-plus:
configuration:
local-cache-scope: statement
方案二：變更localcache的key，使this.localCache.getObject(key)取到的值為null
我們先看下key的構成
public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {
if (this.closed) {
throw new ExecutorException("Executor was closed.");
} else {
CacheKey cacheKey = new CacheKey();
cacheKey.update(ms.getId());
cacheKey.update(rowBounds.getOffset());
cacheKey.update(rowBounds.getLimit());
cacheKey.update(boundSql.getSql());
List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();
Iterator var8 = parameterMappings.iterator();
while(var8.hasNext()) {
ParameterMapping parameterMapping = (ParameterMapping)var8.next();
if (parameterMapping.getMode() != ParameterMode.OUT) {
String propertyName = parameterMapping.getProperty();
Object value;
if (boundSql.hasAdditionalParameter(propertyName)) {
value = boundSql.getAdditionalParameter(propertyName);
} else if (parameterObject == null) {
value = null;
} else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
value = parameterObject;
} else {
MetaObject metaObject = this.configuration.newMetaObject(parameterObject);
value = metaObject.getValue(propertyName);
}
cacheKey.update(value);
}
}
if (this.configuration.getEnvironment() != null) {
cacheKey.update(this.configuration.getEnvironment().getId());
}
return cacheKey;
}
}
從源碼可以看出key是由statementId+原生sql+value（查詢出來的對象）+ sqlsession.hashcode組成。
因此變更key，我們可以從原生sql入手。看到這邊可能有朋友會說，租戶id正常不都不一樣嗎，既然mybatis-plus通過多租戶插件，其產生的sql語句不都不一樣嗎，進而產生的key不就都不一樣了嗎。如果跟蹤源碼就會發現其原生的sql是沒有加上租戶信息的。因此我們可以取巧在查詢的sql語句中添加一個隨機數，形如下
public Optional<SaasUser> findByUserPhone(String userPhone) {
LambdaQueryWrapper<SaasUser> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(SaasUser::getUserPhone,userPhone);
wrapper.apply("{0} = {0}",UUID.randomUUID().toString());
SaasUser saasUser = getBaseMapper().selectOne(wrapper);
return Optional.ofNullable(saasUser);
}
即在原先的代碼查詢語句多加
wrapper.apply("{0} = {0}",UUID.randomUUID().toString());
此時sql語句如下
Preparing: SELECT id, user_code, user_name, main_accout_flag, user_pwd, user_phone, admin_flag, user_status, last_login_time, login_ip, pwd_update_time, tenant_id, create_date, created_by, created_by_id, last_updated_by, last_updated_by_id, last_update_date, object_version_number, delete_flag FROM saas_user WHERE delete_flag = 0 AND (user_phone = ? AND ? = ?) AND tenant_id = 424210194470490118
==> Parameters: 111111(String), edcda7fe-ee43-481a-90f7-8b41cb51a3d1(String), edcda7fe-ee43-481a-90f7-8b41cb51a3d1(String)
這樣每次產生的sql就會不一樣，導致取到不一樣key，進而使this.localCache.getObject(key)為空，這樣就可以讓mybatis每次都進行數據庫查詢，從而達到禁用一級緩存的目的
總結
方案一的配置是基於全局配置，方案二是基於局部配置。就個人而言，是比較推薦方案二，即通過添加隨機值的方式。因為mybatis配置一級緩存的意義，本身就是出於提供性能考慮。不過方案要站在業務的視角進行考慮，為了確保功能能正確運行，有時候犧牲一些性能也無傷大雅