Laravel Redis连接：select操作为何会影响已存在的连接？

Laravel Redis连接：select操作影响已有连接的分析

在Laravel框架中使用Redis时，可能会遇到一个问题：通过配置文件获取的Redis连接，例如Redis::connection('config1')，如果执行select()操作切换数据库，会影响之前已获取的同名连接。

问题现象：

代码首先获取Redis::connection('config1')，然后再次获取同名连接，并使用select(3)切换到数据库3。令人困惑的是，第一次获取的连接随后执行set()操作，数据却写入到数据库3，而非配置文件中指定的数据库2。这与预期不符，因为我们通常认为两次Redis::connection('config1')应该返回不同的实例。

代码示例：

'config1' => [
    'host' => 'xx',
    'password' => 'xx',
    'port' => 'xx',
    'database' => 2
],
$a = Redis::connection('config1');
$b = Redis::connection('config1');
$b->select(3);
$a->set('test1', 1); // 'test1' 写入数据库 3

问题根源：

Laravel的Redis Facade实际上由IlluminateRedisRedisManager管理连接。RedisManager的connection()方法在第一次获取特定名称的连接时创建并保存该实例。后续请求同名连接时，RedisManager直接返回已保存的实例，而非创建新实例。

因此，$a和$b指向同一个Redis连接实例。当$b执行select(3)后，$a也受到影响，因为它们共享同一个底层连接。

解决方案：

为了避免这个问题，应使用Laravel的resolve()方法创建新的Redis连接，而不是重复使用connection()方法获取同一个实例。resolve()方法确保每个连接实例都是独立的，互不干扰。

改进后的代码：

$a = Redis::connection('config1');
$b = app('redis')->connection('config1'); // 使用 resolve 方法创建新的连接
$b->select(3);
$a->set('test1', 1); // 'test1' 写入数据库 2

通过使用app('redis')->connection('config1')或等效的resolve(IlluminateRedisRedisManager::class)->connection('config1')，我们强制Laravel创建一个新的Redis连接实例，从而避免select()操作影响到已存在的连接。 这确保了每个连接的数据库选择是独立管理的。