作者：vivo 網際網路伺服器團隊-Wang Fei
Redis是一種基於客戶端-服務端模型以及請求/響應的TCP服務。在遇到批處理命令執行時，Redis提供了Pipelining(管道)來提升批處理效能。本文結合實踐分析了Spring Boot框架下Redis的Lettuce客戶端和Redisson客戶端對Pipeline特性的支援原理，並針對實踐過程中遇到的問題進行了分析，可以幫助開發者瞭解不同客戶端對Pipeline支援原理及避免實際使用中出現問題。
一、前言
Redis 已經提供了像 mget 、mset 這種批次的命令，但是某些操作根本就不支援或沒有批次的操作，從而與 Redis 高效能背道而馳。為此, Redis基於管道機制，提供Redis Pipeline新特性。Redis Pipeline是一種透過一次性傳送多條命令並在執行完後一次性將結果返回，從而減少客戶端與redis的通訊次數來實現降低往返延時時間提升操作效能的技術。目前，Redis Pipeline是被很多個版本的Redis 客戶端所支援的。
二、Pipeline 底層原理分析
2.1 Redis單個命令執行基本步驟
Redis是一種基於客戶端-服務端模型以及請求/響應的TCP服務。一次Redis客戶端發起的請求，經過服務端的響應後，大致會經歷如下的步驟：
-
客戶端發起一個（查詢/插入）請求，並監聽socket返回，通常情況都是阻塞模式等待Redis伺服器的響應。
-
服務端處理命令，並且返回處理結果給客戶端。
-
客戶端接收到服務的返回結果，程式從阻塞程式碼處返回。
2.2 RTT 時間
Redis客戶端和服務端之間透過網路連線進行資料傳輸，資料包從客戶端到達伺服器，並從伺服器返回資料回覆客戶端的時間被稱之為RTT(Round Trip Time - 往返時間)。我們可以很容易就意識到，Redis在連續請求服務端時，如果RTT時間為250ms, 即使Redis每秒能處理100k請求，但也會因為網路傳輸花費大量時間，導致每秒最多也只能處理4個請求，導致整體效能的下降。
2.3 Redis Pipeline
為了提升效率，這時候Pipeline出現了。Pipelining不僅僅能夠降低RRT，實際上它極大的提升了單次執行的運算元。這是因為如果不使用Pipelining，那麼每次執行單個命令,從訪問資料的結構和服務端產生應答的角度，它的成本是很低的。但是從執行網路IO的角度，它的成本其實是很高的。其中涉及到read()和write()的系統呼叫，這意味著需要從使用者態切換到核心態,而這個上下文的切換成本是巨大的。
當使用Pipeline時，它允許多個命令的讀透過一次read()操作，多個命令的應答使用一次write()操作，它允許客戶端可以一次傳送多條命令，而不等待上一條命令執行的結果。不僅減少了RTT，同時也減少了IO呼叫次數（IO呼叫涉及到使用者態到核心態之間的切換），最終提升程式的執行效率與效能。如下圖：
要支援Pipeline，其實既要服務端的支援，也要客戶端支援。對於服務端來說，所需要的是能夠處理一個客戶端透過同一個TCP連線發來的多個命令，可以理解為，這裡將多個命令切分，和處理單個命令一樣，Redis就是這樣處理的。而客戶端，則是要將多個命令快取起來，緩衝區滿了就傳送，然後再寫緩衝，最後才處理Redis的應答。
三、Pipeline 基本使用及效能比較
下面我們以給10w個set結構分別插入一個整數值為例，分別使用jedis單個命令插入、jedis使用Pipeline模式進行插入和redisson使用Pipeline模式進行插入以及測試其耗時。
@Slf4j
public class RedisPipelineTestDemo {
public static void main(String[] args) {
//連線redis
Jedis jedis = new Jedis("10.101.17.180", 6379);
//jedis逐一給每個set新增一個value
String zSetKey = "Pipeline-test-set";
int size = 100000;
long begin = System.currentTimeMillis();
for (int i = 0; i < size; i++) {
jedis.sadd(zSetKey + i, "aaa");
}
log.info("Jedis逐一給每個set新增一個value耗時：{}ms", (System.currentTimeMillis() - begin));
//Jedis使用Pipeline模式 Pipeline Pipeline = jedis.Pipelined();
begin = System.currentTimeMillis();
for (int i = 0; i < size; i++) { Pipeline.sadd(zSetKey + i, "bbb");
} Pipeline.sync();
log.info("Jedis Pipeline模式耗時：{}ms", (System.currentTimeMillis() - begin));
//Redisson使用Pipeline模式
Config config = new Config();
config.useSingleServer().setAddress("redis://10.101.17.180:6379");
RedissonClient redisson = Redisson.create(config);
RBatch redisBatch = redisson.createBatch();
begin = System.currentTimeMillis();
for (int i = 0; i < size; i++) {
redisBatch.getSet(zSetKey + i).addAsync("ccc");
}
redisBatch.execute();
log.info("Redisson Pipeline模式耗時：{}ms", (System.currentTimeMillis() - begin));
//關閉 Pipeline.close();
jedis.close();
redisson.shutdown();
}
}測試結果如下:
Jedis逐一給每個set新增一個value耗時：162655ms
Jedis Pipeline模式耗時：504ms
Redisson Pipeline模式耗時：1399ms
我們發現使用Pipeline模式對應的效能會明顯好於單個命令執行的情況。
四、專案中實際應用
在實際使用過程中有這樣一個場景，很多應用在節假日的時候需要更新應用圖示樣式，在運營進行後臺配置的時候, 可以根據圈選的使用者標籤預先計算出單個使用者需要下發的圖示樣式並儲存在Redis裡面，從而提升效能，這裡就涉及Redis的批次操作問題，業務流程如下：
為了提升Redis操作效能，我們決定使用Redis Pipelining機制進行批次執行。
4.1 Redis 客戶端對比
針對Java技術棧而言，目前Redis使用較多的客戶端為Jedis、Lettuce和Redisson。
目前專案主要是基於SpringBoot開發，針對Redis，其預設的客戶端為Lettuce，所以我們基於Lettuce客戶端進行分析。
4.2 Spring環境下Lettuce客戶端對Pipeline的實現
在Spring環境下，使用Redis的Pipeline也是很簡單的。spring-data-redis提供了StringRedisTemplate簡化了對Redis的操作, 只需要呼叫StringRedisTemplate的executePipelined方法就可以了，但是在引數中提供了兩種回撥方式：SessionCallback和RedisCallback。
兩種使用方式如下(這裡以操作set結構為例)：
-
RedisCallback的使用方式：
public void testRedisCallback() {
List<Integer> ids= Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
Integer contentId = 1;
redisTemplate.executePipelined(new InsertPipelineExecutionA(ids, contentId));
}
@AllArgsConstructor
private static class InsertPipelineExecutionA implements RedisCallback<Void> {
private final List<Integer> ids;
private final Integer contentId;
@Override
public Void doInRedis(RedisConnection connection) DataAccessException {
RedisSetCommands redisSetCommands = connection.setCommands();
ids.forEach(id-> {
String redisKey = "aaa:" + id;
String value = String.valueOf(contentId);
redisSetCommands.sAdd(redisKey.getBytes(), value.getBytes());
});
return null;
}
}- SessionCallback的使用方式：
public void testSessionCallback() {
List<Integer> ids= Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9);
Integer contentId = 1;
redisTemplate.executePipelined(new InsertPipelineExecutionB(ids, contentId));
}
@AllArgsConstructor
private static class InsertPipelineExecutionB implements SessionCallback<Void> {
private final List<Integer> ids;
private final Integer contentId;
@Override
public <K, V> Void execute(RedisOperations<K, V> operations) throws DataAccessException {
SetOperations<String, String> setOperations = (SetOperations<String, String>) operations.opsForSet();
ids.forEach(id-> {
String redisKey = "aaa:" + id;
String value = String.valueOf(contentId);
setOperations.add(redisKey, value);
});
return null;
}
}4.3 RedisCallBack和SessionCallback之間的比較
1、RedisCallBack和SessionCallback都可以實現回撥，透過它們可以在同一條連線中一次執行多個redis命令。
2、RedisCallback使用的是原生RedisConnection，用起來比較麻煩，比如上面執行set的add操作，key和value需要進行轉換，可讀性差，但原生api提供的功能比較齊全。
3、SessionCalback提供了良好的封裝，可以優先選擇使用這種回撥方式。
最終的程式碼實現如下：
public void executeB(List<Integer> userIds, Integer iconId) {
redisTemplate.executePipelined(new InsertPipelineExecution(userIds, iconId));
}
@AllArgsConstructor
private static class InsertPipelineExecution implements SessionCallback<Void> {
private final List<Integer> userIds;
private final Integer iconId;
@Override
public <K, V> Void execute(RedisOperations<K, V> operations) throws DataAccessException {
SetOperations<String, String> setOperations = (SetOperations<String, String>) operations.opsForSet();
userIds.forEach(userId -> {
String redisKey = "aaa:" + userId;
String value = String.valueOf(iconId);
setOperations.add(redisKey, value);
});
return null;
}
}4.4 原始碼分析
那麼為什麼使用Pipeline方式會對效能有較大提升呢，我們現在從原始碼入手著重分析一下：
4.4.1 Pipeline方式下獲取連線相關原理分析：
@Override
public List<Object> executePipelined(SessionCallback<?> session, @Nullable RedisSerializer<?> resultSerializer) {
Assert.isTrue(initialized, "template not initialized; call afterPropertiesSet() before using it");
Assert.notNull(session, "Callback object must not be null");
//1. 獲取對應的Redis連線工廠
RedisConnectionFactory factory = getRequiredConnectionFactory();
//2. 繫結連線過程
RedisConnectionUtils.bindConnection(factory, enableTransactionSupport);
try {
//3. 執行命令流程, 這裡請求引數為RedisCallback, 裡面有對應的回撥操作
return execute((RedisCallback<List<Object>>) connection -> {
//具體的回撥邏輯
connection.openPipeline();
boolean PipelinedClosed = false;
try {
//執行命令
Object result = executeSession(session);
if (result != null) {
throw new InvalidDataAccessApiUsageException(
"Callback cannot return a non-null value as it gets overwritten by the Pipeline");
}
List<Object> closePipeline = connection.closePipeline(); PipelinedClosed = true;
return deserializeMixedResults(closePipeline, resultSerializer, hashKeySerializer, hashValueSerializer);
} finally {
if (!PipelinedClosed) {
connection.closePipeline();
}
}
});
} finally {
RedisConnectionUtils.unbindConnection(factory);
}
}① 獲取對應的Redis連線工廠，這裡要使用Pipeline特性需要使用LettuceConnectionFactory方式，這裡獲取的連線工廠就是LettuceConnectionFactory。
② 繫結連線過程，具體指的是將當前連線繫結到當前執行緒上面， 核心方法為：doGetConnection。
public static RedisConnection doGetConnection(RedisConnectionFactory factory, boolean allowCreate, boolean bind,
boolean enableTransactionSupport) {
Assert.notNull(factory, "No RedisConnectionFactory specified");
//核心類，有快取作用，下次可以從這裡獲取已經存在的連線
RedisConnectionHolder connHolder = (RedisConnectionHolder) TransactionSynchronizationManager.getResource(factory);
//如果connHolder不為null, 則獲取已經存在的連線, 提升效能
if (connHolder != null) {
if (enableTransactionSupport) {
potentiallyRegisterTransactionSynchronisation(connHolder, factory);
}
return connHolder.getConnection();
}
......
//第一次獲取連線，需要從Redis連線工廠獲取連線
RedisConnection conn = factory.getConnection();
//bind = true 執行繫結
if (bind) {
RedisConnection connectionToBind = conn;
......
connHolder = new RedisConnectionHolder(connectionToBind);
//繫結核心程式碼: 將獲取的連線和當前執行緒繫結起來
TransactionSynchronizationManager.bindResource(factory, connHolder);
......
return connHolder.getConnection();
}
return conn;
}裡面有個核心類RedisConnectionHolder，我們看一下RedisConnectionHolder connHolder =
(RedisConnectionHolder) TransactionSynchronizationManager.getResource(factory);
@Nullable
public static Object getResource(Object key) {
Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
Object value = doGetResource(actualKey);
if (value != null && logger.isTraceEnabled()) {
logger.trace("Retrieved value [" + value + "] for key [" + actualKey + "] bound to thread [" +
Thread.currentThread().getName() + "]");
}
return value;
}裡面有一個核心方法doGetResource(actualKey)，大家很容易猜測這裡涉及到一個map結構，如果我們看原始碼，也確實是這樣一個結構。
@Nullable
private static Object doGetResource(Object actualKey) {
Map<Object, Object> map = resources.get();
if (map == null) {
return null;
}
Object value = map.get(actualKey);
// Transparently remove ResourceHolder that was marked as void...
if (value instanceof ResourceHolder && ((ResourceHolder) value).isVoid()) {
map.remove(actualKey);
// Remove entire ThreadLocal if empty...
if (map.isEmpty()) {
resources.remove();
}
value = null;
}
return value;
}resources是一個ThreadLocal型別，這裡會涉及到根據RedisConnectionFactory獲取到連線connection的邏輯,如果下一次是同一個actualKey，那麼就直接使用已經存在的連線，而不需要新建一個連線。第一次這裡map為null，就直接返回了，然後回到doGetConnection方法，由於這裡bind為true，我們會執行TransactionSynchronizationManager.bindResource(factory, connHolder);，也就是將連線和當前執行緒繫結了起來。
public static void bindResource(Object key, Object value) throws IllegalStateException {
Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
Assert.notNull(value, "Value must not be null");
Map<Object, Object> map = resources.get();
// set ThreadLocal Map if none found
if (map == null) {
map = new HashMap<>();
resources.set(map);
}
Object oldValue = map.put(actualKey, value);
......
}③ 我們回到executePipelined，在獲取到連線工廠，將連線和當前執行緒繫結起來以後，就開始需要正式去執行命令了, 這裡會呼叫execute方法
@Override
@Nullable
public <T> T execute(RedisCallback<T> action) {
return execute(action, isExposeConnection());
}這裡我們注意到execute方法的入參為RedisCallback<T>action，RedisCallback對應的doInRedis操作如下,這裡在後面的呼叫過程中會涉及到回撥。
connection.openPipeline();
boolean PipelinedClosed = false;
try {
Object result = executeSession(session);
if (result != null) {
throw new InvalidDataAccessApiUsageException(
"Callback cannot return a non-null value as it gets overwritten by the Pipeline");
}
List<Object> closePipeline = connection.closePipeline(); PipelinedClosed = true;
return deserializeMixedResults(closePipeline, resultSerializer, hashKeySerializer, hashValueSerializer);
} finally {
if (!PipelinedClosed) {
connection.closePipeline();
}
}我們再來看execute(action, isExposeConnection())方法，這裡最終會呼叫<T>execute(RedisCallback<T>action, boolean exposeConnection, boolean Pipeline)方法。
@Nullable
public <T> T execute(RedisCallback<T> action, boolean exposeConnection, boolean Pipeline) {
Assert.isTrue(initialized, "template not initialized; call afterPropertiesSet() before using it");
Assert.notNull(action, "Callback object must not be null");
//獲取對應的連線工廠
RedisConnectionFactory factory = getRequiredConnectionFactory();
RedisConnection conn = null;
try {
if (enableTransactionSupport) {
// only bind resources in case of potential transaction synchronization
conn = RedisConnectionUtils.bindConnection(factory, enableTransactionSupport);
} else {
//獲取對應的連線(enableTransactionSupport=false)
conn = RedisConnectionUtils.getConnection(factory);
}
boolean existingConnection = TransactionSynchronizationManager.hasResource(factory);
RedisConnection connToUse = preProcessConnection(conn, existingConnection);
boolean PipelineStatus = connToUse.isPipelined();
if (Pipeline && !PipelineStatus) {
connToUse.openPipeline();
}
RedisConnection connToExpose = (exposeConnection ? connToUse : createRedisConnectionProxy(connToUse));
//核心方法，這裡就開始執行回撥操作
T result = action.doInRedis(connToExpose);
// close Pipeline
if (Pipeline && !PipelineStatus) {
connToUse.closePipeline();
}
// TODO: any other connection processing?
return postProcessResult(result, connToUse, existingConnection);
} finally {
RedisConnectionUtils.releaseConnection(conn, factory, enableTransactionSupport);
}
}我們看到這裡最開始也是獲取對應的連線工廠，然後獲取對應的連線(enableTransactionSupport=false)，具體呼叫是RedisConnectionUtils.getConnection(factory)方法，最終會呼叫RedisConnection doGetConnection(RedisConnectionFactory factory, booleanallowCreate, boolean bind, boolean enableTransactionSupport)，此時bind為false
public static RedisConnection doGetConnection(RedisConnectionFactory factory, boolean allowCreate, boolean bind,
boolean enableTransactionSupport) {
Assert.notNull(factory, "No RedisConnectionFactory specified");
//直接獲取與當前執行緒繫結的Redis連線
RedisConnectionHolder connHolder = (RedisConnectionHolder) TransactionSynchronizationManager.getResource(factory);
if (connHolder != null) {
if (enableTransactionSupport) {
potentiallyRegisterTransactionSynchronisation(connHolder, factory);
}
return connHolder.getConnection();
}
......
return conn;
}前面我們分析過一次，這裡呼叫RedisConnectionHolder connHolder = (RedisConnectionHolder)TransactionSynchronizationManager.getResource(factory);會獲取到之前和當前執行緒繫結的Redis，而不會新建立一個連線。
然後會去執行T result = action.doInRedis(connToExpose)，這裡的action為RedisCallback，執行doInRedis為：
//開啟Pipeline功能
connection.openPipeline();
boolean PipelinedClosed = false;
try {
//執行Redis命令
Object result = executeSession(session);
if (result != null) {
throw new InvalidDataAccessApiUsageException(
"Callback cannot return a non-null value as it gets overwritten by the Pipeline");
}
List<Object> closePipeline = connection.closePipeline(); PipelinedClosed = true;
return deserializeMixedResults(closePipeline, resultSerializer, hashKeySerializer, hashValueSerializer);
} finally {
if (!PipelinedClosed) {
connection.closePipeline();
}
}這裡最開始會開啟Pipeline功能，然後執行Object result = executeSession(session);
private Object executeSession(SessionCallback<?> session) {
return session.execute(this);
}這裡會呼叫我們自定義的execute方法
@AllArgsConstructor
private static class InsertPipelineExecution implements SessionCallback<Void> {
private final List<Integer> userIds;
private final Integer iconId;
@Override
public <K, V> Void execute(RedisOperations<K, V> operations) throws DataAccessException {
SetOperations<String, String> setOperations = (SetOperations<String, String>) operations.opsForSet();
userIds.forEach(userId -> {
String redisKey = "aaa:" + userId;
String value = String.valueOf(iconId);
setOperations.add(redisKey, value);
});
return null;
}
}進入到foreach迴圈，執行DefaultSetOperations的add方法。
@Override
public Long add(K key, V... values) {
byte[] rawKey = rawKey(key);
byte[][] rawValues = rawValues((Object[]) values);
//這裡的connection.sAdd是後續回撥要執行的方法
return execute(connection -> connection.sAdd(rawKey, rawValues), true);
}這裡會繼續執行redisTemplate的execute方法，裡面最終會呼叫我們之前分析過的<T>T execute(RedisCallback<T>action, boolean exposeConnection, boolean Pipeline)方法。
@Nullable
public <T> T execute(RedisCallback<T> action, boolean exposeConnection, boolean Pipeline) {
Assert.isTrue(initialized, "template not initialized; call afterPropertiesSet() before using it");
Assert.notNull(action, "Callback object must not be null");
RedisConnectionFactory factory = getRequiredConnectionFactory();
RedisConnection conn = null;
try {
......
//再次執行回撥方法，這裡執行的Redis基本資料結構對應的操作命令
T result = action.doInRedis(connToExpose);
......
// TODO: any other connection processing?
return postProcessResult(result, connToUse, existingConnection);
} finally {
RedisConnectionUtils.releaseConnection(conn, factory, enableTransactionSupport);
}
}這裡會繼續執行T result = action.doInRedis(connToExpose);，這裡其實執行的doInRedis方法為：
connection -> connection.sAdd(rawKey, rawValues)4.4.2 Pipeline方式下執行命令的流程分析:
① 接著上面的流程分析，這裡的sAdd方法實際呼叫的是DefaultStringRedisConnection的sAdd方法
@Override
public Long sAdd(byte[] key, byte[]... values) {
return convertAndReturn(delegate.sAdd(key, values), identityConverter);
}② 這裡會進一步呼叫DefaultedRedisConnection的sAdd方法
@Override
@Deprecated
default Long sAdd(byte[] key, byte[]... values) {
return setCommands().sAdd(key, values);
}③ 接著呼叫LettuceSetCommands的sAdd方法
@Override
public Long sAdd(byte[] key, byte[]... values) {
Assert.notNull(key, "Key must not be null!");
Assert.notNull(values, "Values must not be null!");
Assert.noNullElements(values, "Values must not contain null elements!");
try {
// 如果開啟了 Pipelined 模式，獲取的是 非同步連線，進行非同步操作
if (isPipelined()) { Pipeline(connection.newLettuceResult(getAsyncConnection().sadd(key, values)));
return null;
}
if (isQueueing()) {
transaction(connection.newLettuceResult(getAsyncConnection().sadd(key, values)));
return null;
}
//常規模式下，使用的是同步操作
return getConnection().sadd(key, values);
} catch (Exception ex) {
throw convertLettuceAccessException(ex);
}
}這裡我們開啟了Pipeline, 實際會呼叫Pipeline(connection.newLettuceResult(getAsyncConnection().sadd(key, values))); 也就是獲取非同步連線getAsyncConnection，然後進行非同步操作sadd，而常規模式下，使用的是同步操作，所以在Pipeline模式下，執行效率更高。
從上面的獲取連線和具體命令執行相關原始碼分析可以得出使用Lettuce客戶端Pipeline模式高效的根本原因：
-
普通模式下，每執行一個命令都需要先開啟一個連線，命令執行完畢以後又需要關閉這個連線，執行下一個命令時，又需要經過連線開啟和關閉的流程；而Pipeline的所有命令的執行只需要經過一次連線開啟和關閉。
-
普通模式下命令的執行是同步阻塞模式，而Pipeline模式下命令的執行是非同步非阻塞模式。
五、專案中遇到的坑
前面介紹了涉及到批次操作，可以使用Redis Pipelining機制，那是不是任何批次操作相關的場景都可以使用呢，比如list型別資料的批次移除操作，我們的程式碼最開始是這麼寫的：
public void deleteSet(String updateKey, Set<Integer> userIds) {
if (CollectionUtils.isEmpty(userIds)) {
return;
}
redisTemplate.executePipelined(new DeleteListCallBack(userIds, updateKey));
}
@AllArgsConstructor
private static class DeleteListCallBack implements SessionCallback<Object> {
private Set<Integer> userIds;
private String updateKey;
@Override
public <K, V> Object execute(RedisOperations<K, V> operations) throws DataAccessException {
ListOperations<String, String> listOperations = (ListOperations<String, String>) operations.opsForList();
userIds.forEach(userId -> listOperations.remove(updateKey, 1, userId.toString()));
return null;
}
}在資料量比較小的時候沒有出現問題，直到有一條收到了Redis的記憶體和cpu利用率的告警訊息，我們發現這麼使用是有問題的，核心原因在於list的lrem操作的時間複雜度是O(N+M)，其中N是list的長度, M是要移除的元素的個數，而我們這裡還是一個一個移除的，當然會導致Redis資料積壓和cpu每秒ops升高導致cpu利用率飈高。也就是說，即使使用Pipeline進行批次操作，但是由於單次操作很耗時，是會導致整個Redis出現問題的。
後面我們進行了最佳化，選用了list的ltrim命令，一次命令執行批次remove操作：
public void deleteSet(String updateKey, Set<Integer> deviceIds) {
if (CollectionUtils.isEmpty(deviceIds)) {
return;
}
int maxSize = 10000;
redisTemplate.opsForList().trim(updateKey, maxSize + 1, -1);
}由於ltrim本身的時間複雜度為O(M), 其中M要移除的元素的個數，相比於原始方案的lrem，效率提升很多，可以不需要使用Redis Pipeline，最佳化結果使得Redis記憶體利用率和cpu利用率都極大程度得到緩解。
六、Redisson 對 Redis Pipeline 特性支援
在redisson官方文件中額外特性介紹中有說到批次命令執行這個特性， 也就是多個命令在一次網路呼叫中集中傳送，該特性是RBatch這個類支援的，從這個類的描述來看，主要是為Redis Pipeline這個特性服務的，並且主要是透過佇列和非同步實現的。
/**
* Interface for using Redis Pipeline feature.
* <p>
* All method invocations on objects got through this interface
* are batched to separate queue and could be executed later
* with <code>execute()</code> or <code>executeAsync()</code> methods.
*
*
* @author Nikita Koksharov
*
*/
public interface RBatch {
/**
* Returns stream instance by <code>name</code>
*
* @param <K> type of key
* @param <V> type of value
* @param name of stream
* @return RStream object
*/
<K, V> RStreamAsync<K, V> getStream(String name);
/**
* Returns stream instance by <code>name</code>
* using provided <code>codec</code> for entries.
*
* @param <K> type of key
* @param <V> type of value
* @param name - name of stream
* @param codec - codec for entry
* @return RStream object
*/
<K, V> RStreamAsync<K, V> getStream(String name, Codec codec);
......
/**
* Returns list instance by name.
*
* @param <V> type of object
* @param name - name of object
* @return List object
*/
<V> RListAsync<V> getList(String name);
<V> RListAsync<V> getList(String name, Codec codec);
......
/**
* Executes all operations accumulated during async methods invocations.
* <p>
* If cluster configuration used then operations are grouped by slot ids
* and may be executed on different servers. Thus command execution order could be changed
*
* @return List with result object for each command
* @throws RedisException in case of any error
*
*/
BatchResult<?> execute() throws RedisException;
/**
* Executes all operations accumulated during async methods invocations asynchronously.
* <p>
* In cluster configurations operations grouped by slot ids
* so may be executed on different servers. Thus command execution order could be changed
*
* @return List with result object for each command
*/
RFuture<BatchResult<?>> executeAsync();
/**
* Discard batched commands and release allocated buffers used for parameters encoding.
*/
void discard();
/**
* Discard batched commands and release allocated buffers used for parameters encoding.
*
* @return void
*/
RFuture<Void> discardAsync();
}簡單的測試程式碼如下：
@Slf4j
public class RedisPipelineTest {
public static void main(String[] args) {
//Redisson使用Pipeline模式
Config config = new Config();
config.useSingleServer().setAddress("redis://xx.xx.xx.xx:6379");
RedissonClient redisson = Redisson.create(config);
RBatch redisBatch = redisson.createBatch();
int size = 100000;
String zSetKey = "Pipeline-test-set";
long begin = System.currentTimeMillis();
//將命令放入佇列中
for (int i = 0; i < size; i++) {
redisBatch.getSet(zSetKey + i).addAsync("ccc");
}
//批次執行命令
redisBatch.execute();
log.info("Redisson Pipeline模式耗時：{}ms", (System.currentTimeMillis() - begin));
//關閉
redisson.shutdown();
}
}核心方法分析：
1.建Redisson客戶端RedissonClient redisson = redisson.create(config), 該方法最終會呼叫Reddison的構造方法Redisson(Config config)。
protected Redisson(Config config) {
this.config = config;
Config configCopy = new Config(config);
connectionManager = ConfigSupport.createConnectionManager(configCopy);
RedissonObjectBuilder objectBuilder = null;
if (config.isReferenceEnabled()) {
objectBuilder = new RedissonObjectBuilder(this);
}
//新建非同步命令執行器
commandExecutor = new CommandSyncService(connectionManager, objectBuilder);
//執行刪除超時任務的定時器
evictionScheduler = new EvictionScheduler(commandExecutor);
writeBehindService = new WriteBehindService(commandExecutor);
}該構造方法中會新建非同步命名執行器CommandAsyncExecutor commandExecutor和使用者刪除超時任務的EvictionScheduler evictionScheduler。
2.建立RBatch例項RBatch redisBatch = redisson.createBatch()， 該方法會使用到步驟1中的commandExecutor和evictionScheduler例項物件。
@Override
public RBatch createBatch(BatchOptions options) {
return new RedissonBatch(evictionScheduler, commandExecutor, options);
}
public RedissonBatch(EvictionScheduler evictionScheduler, CommandAsyncExecutor executor, BatchOptions options) {
this.executorService = new CommandBatchService(executor, options);
this.evictionScheduler = evictionScheduler;
}其中的options物件會影響後面批次執行命令的流程。
3. 非同步給set集合新增元素的操作addAsync，這裡會具體呼叫RedissonSet的addAsync方法
@Override
public RFuture<Boolean> addAsync(V e) {
String name = getRawName(e);
return commandExecutor.writeAsync(name, codec, RedisCommands.SADD_SINGLE, name, encode(e));
}（1）接著呼叫CommandAsyncExecutor的非同步寫入方法writeAsync。
@Override
public <T, R> RFuture<R> writeAsync(String key, Codec codec, RedisCommand<T> command, Object... params) {
RPromise<R> mainPromise = createPromise();
NodeSource source = getNodeSource(key);
async(false, source, codec, command, params, mainPromise, false);
return mainPromise;
}（2） 接著呼叫批次命令執行器CommandBatchService的非同步傳送命令。
@Override
public <V, R> void async(boolean readOnlyMode, NodeSource nodeSource,
Codec codec, RedisCommand<V> command, Object[] params, RPromise<R> mainPromise, boolean ignoreRedirect) {
if (isRedisBasedQueue()) {
boolean isReadOnly = options.getExecutionMode() == ExecutionMode.REDIS_READ_ATOMIC;
RedisExecutor<V, R> executor = new RedisQueuedBatchExecutor<>(isReadOnly, nodeSource, codec, command, params, mainPromise,
false, connectionManager, objectBuilder, commands, connections, options, index, executed, latch, referenceType);
executor.execute();
} else {
//執行分支
RedisExecutor<V, R> executor = new RedisBatchExecutor<>(readOnlyMode, nodeSource, codec, command, params, mainPromise,
false, connectionManager, objectBuilder, commands, options, index, executed, referenceType);
executor.execute();
}
}（3） 接著呼叫了RedisBatchExecutor.execute方法和BaseRedisBatchExecutor.addBatchCommandData方法。
@Override
public void execute() {
addBatchCommandData(params);
}
protected final void addBatchCommandData(Object[] batchParams) {
MasterSlaveEntry msEntry = getEntry(source);
Entry entry = commands.get(msEntry);
if (entry == null) {
entry = new Entry();
Entry oldEntry = commands.putIfAbsent(msEntry, entry);
if (oldEntry != null) {
entry = oldEntry;
}
}
if (!readOnlyMode) {
entry.setReadOnlyMode(false);
}
Codec codecToUse = getCodec(codec);
BatchCommandData<V, R> commandData = new BatchCommandData<V, R>(mainPromise, codecToUse, command, batchParams, index.incrementAndGet());
entry.getCommands().add(commandData);
}這裡的commands以主節點為KEY,以待傳送命令佇列列表為VALUE(Entry)，儲存一個MAP.然後會把命令都新增到entry的commands命令佇列中， Entry結構如下面程式碼所示。
public static class Entry {
Deque<BatchCommandData<?, ?>> commands = new LinkedBlockingDeque<>();
volatile boolean readOnlyMode = true;
public Deque<BatchCommandData<?, ?>> getCommands() {
return commands;
}
public void setReadOnlyMode(boolean readOnlyMode) {
this.readOnlyMode = readOnlyMode;
}
public boolean isReadOnlyMode() {
return readOnlyMode;
}
public void clearErrors() {
for (BatchCommandData<?, ?> commandEntry : commands) {
commandEntry.clearError();
}
}
}4. 批次執行命令redisBatch.execute()，這裡會最終呼叫CommandBatchService的executeAsync方法，該方法完整程式碼如下，我們下面來逐一進行拆解。
public RFuture<BatchResult<?>> executeAsync() {
......
RPromise<BatchResult<?>> promise = new RedissonPromise<>();
RPromise<Void> voidPromise = new RedissonPromise<Void>();
if (this.options.isSkipResult()
&& this.options.getSyncSlaves() == 0) {
......
} else {
//這裡是對非同步執行結果進行處理,可以先忽略, 後面會詳細講，先關注批次執行命令的邏輯
voidPromise.onComplete((res, ex) -> {
......
});
}
AtomicInteger slots = new AtomicInteger(commands.size());
......
//真正執行的程式碼入口，批次執行命令
for (Map.Entry<MasterSlaveEntry, Entry> e : commands.entrySet()) {
RedisCommonBatchExecutor executor = new RedisCommonBatchExecutor(new NodeSource(e.getKey()), voidPromise,
connectionManager, this.options, e.getValue(), slots, referenceType);
executor.execute();
}
return promise;
}裡面會用到我們在3.3步驟所生成的commands例項。
（1）接著呼叫了基類RedisExecutor的execute方法
public void execute() {
......
connectionFuture.onComplete((connection, e) -> {
if (connectionFuture.isCancelled()) {
connectionManager.getShutdownLatch().release();
return;
}
if (!connectionFuture.isSuccess()) {
connectionManager.getShutdownLatch().release();
exception = convertException(connectionFuture);
return;
}
//呼叫RedisCommonBatchExecutor的sendCommand方法, 裡面會將多個命令放到一個List<CommandData<?, ?>> list列表裡面
sendCommand(attemptPromise, connection);
writeFuture.addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) throws Exception {
checkWriteFuture(writeFuture, attemptPromise, connection);
}
});
});
......
}（2）接著呼叫RedisCommonBatchExecutor的sendCommand方法，裡面會將多個命令放到一個List<commanddata> list列表裡面。
@Override
protected void sendCommand(RPromise<Void> attemptPromise, RedisConnection connection) {
boolean isAtomic = options.getExecutionMode() != ExecutionMode.IN_MEMORY;
boolean isQueued = options.getExecutionMode() == ExecutionMode.REDIS_READ_ATOMIC
|| options.getExecutionMode() == ExecutionMode.REDIS_WRITE_ATOMIC;
//將多個命令放到一個List<CommandData<?, ?>> list列表裡面
List<CommandData<?, ?>> list = new ArrayList<>(entry.getCommands().size());
if (source.getRedirect() == Redirect.ASK) {
RPromise<Void> promise = new RedissonPromise<Void>();
list.add(new CommandData<Void, Void>(promise, StringCodec.INSTANCE, RedisCommands.ASKING, new Object[] {}));
}
for (CommandData<?, ?> c : entry.getCommands()) {
if ((c.getPromise().isCancelled() || c.getPromise().isSuccess())
&& !isWaitCommand(c)
&& !isAtomic) {
// skip command
continue;
}
list.add(c);
}
......
//呼叫RedisConnection的send方法，將命令一次性發到Redis伺服器端
writeFuture = connection.send(new CommandsData(attemptPromise, list, options.isSkipResult(), isAtomic, isQueued, options.getSyncSlaves() > 0));
}（3）接著呼叫RedisConnection的send方法，透過Netty通訊傳送命令到Redis伺服器端執行，這裡也驗證了Redisson客戶端底層是採用Netty進行通訊的。
public ChannelFuture send(CommandsData data) {
return channel.writeAndFlush(data);
}5. 接收返回結果，這裡主要是監聽事件是否完成，然後組裝返回結果, 核心方法是步驟4提到的CommandBatchService的executeAsync方法,裡面會對返回結果進行監聽和處理, 核心程式碼如下：
public RFuture<BatchResult<?>> executeAsync() {
......
RPromise<BatchResult<?>> promise = new RedissonPromise<>();
RPromise<Void> voidPromise = new RedissonPromise<Void>();
if (this.options.isSkipResult()
&& this.options.getSyncSlaves() == 0) {
......
} else {
voidPromise.onComplete((res, ex) -> {
//對返回結果的處理
executed.set(true);
......
List<Object> responses = new ArrayList<Object>(entries.size());
int syncedSlaves = 0;
for (BatchCommandData<?, ?> commandEntry : entries) {
if (isWaitCommand(commandEntry)) {
syncedSlaves = (Integer) commandEntry.getPromise().getNow();
} else if (!commandEntry.getCommand().getName().equals(RedisCommands.MULTI.getName())
&& !commandEntry.getCommand().getName().equals(RedisCommands.EXEC.getName())
&& !this.options.isSkipResult()) {
......
//獲取單個命令的執行結果
Object entryResult = commandEntry.getPromise().getNow();
......
//將單個命令執行結果放到List中
responses.add(entryResult);
}
}
BatchResult<Object> result = new BatchResult<Object>(responses, syncedSlaves);
promise.trySuccess(result);
......
});
}
......
return promise;
}這裡會把單個命令的執行結果放到responses裡面，最終返回RPromise<batchresult>promise。
從上面的分析來看，Redisson客戶端對Redis Pipeline的支援也是從多個命令在一次網路通訊中執行和非同步處理來實現的。
七、總結
Redis提供了Pipelining進行批次操作的高階特性，極大地提高了部分資料型別沒有批次執行命令導致的執行耗時而引起的效能問題，但是我們在使用的過程中需要考慮Pipeline操作中單個命令執行的耗時問題，否則帶來的效果可能適得其反。最後擴充套件分析了Redisson客戶端對Redis Pipeline特性的支援原理，可以與Lettuce客戶端對Redis Pipeline支援原理進行比較，加深Pipeline在不同Redis客戶端實現方式的理解。
參考資料：
-
Redis Pipelining
-
RedisTemplate使用Pipeline管道命令
-
如何使用好Redis Pipeline
-
Redisson 管道批次傳送命令流程分析