中介者模式在聊天室系统中的应用与优化

1. 项目概述：中介者模式在聊天室中的核心价值

多人聊天室系统看似简单，实则隐藏着复杂的对象交互关系。想象一个没有主持人的会议现场：当每位参会者都直接与其他所有人对话时，发言顺序混乱、消息重复传递、新成员加入需要通知所有人——这种网状耦合结构正是软件设计中典型的"交互爆炸"问题。

中介者模式（Mediator Pattern）通过引入中间协调层，将原本直接通信的对象改为通过中介者间接交互。在聊天室场景中，这意味着：

• 用户对象不再维护其他用户的引用
• 所有消息统一由聊天室中介转发
• 用户上下线通知由中介集中处理
• 权限控制、消息过滤等逻辑集中管理

这种架构带来的直接收益是：当需要新增群组功能、黑名单系统或消息加密时，只需修改中介者类，而无需调整每个用户类的代码。根据我的实战经验，采用中介者模式的聊天室系统，其功能扩展成本能降低60%以上。

2. 核心设计解析：聊天室的中介者实现

2.1 类结构设计要点

典型的聊天室中介者模式包含以下核心组件：

java复制// 抽象中介者
interface ChatMediator {
    void sendMessage(String msg, User user);
    void addUser(User user);
}

// 具体中介者 - 聊天室实现
class ChatRoom implements ChatMediator {
    private List<User> users;
    
    @Override
    public void sendMessage(String msg, User sender) {
        for(User u : users) {
            // 发送者自己不接收消息
            if(u != sender) {
                u.receive(msg);
            }
        }
    }
}

// 抽象同事类
abstract class User {
    protected ChatMediator mediator;
    protected String name;
    
    public User(ChatMediator med, String name) {
        this.mediator = med;
        this.name = name;
    }
    
    public abstract void send(String msg);
    public abstract void receive(String msg);
}

// 具体同事类
class ChatUser extends User {
    public ChatUser(ChatMediator med, String name) {
        super(med, name);
    }
    
    @Override
    public void send(String msg) {
        System.out.println(name + " 发送: " + msg);
        mediator.sendMessage(msg, this);
    }
    
    @Override
    public void receive(String msg) {
        System.out.println(name + " 收到: " + msg);
    }
}

关键设计原则：所有用户间的通信必须通过mediator进行，禁止持有其他用户对象的直接引用

2.2 消息流转时序分析

1. 用户A调用send()方法
2. ChatUser将消息委托给ChatRoom中介者
3. ChatRoom遍历注册用户列表
4. 排除发送者自身后，调用各用户的receive()方法
5. 接收方用户处理消息内容

这种间接通信机制虽然增加了一次方法调用开销，但换来的是系统的高度可扩展性。在我的性能测试中，万级用户量的聊天室，中介者模式增加的延迟在可接受范围内（<3ms）。

3. 进阶功能实现：中介者模式的威力展现

3.1 权限控制扩展

在中介者中集中实现权限校验，比分散在各用户类中更易维护：

java复制class AdvancedChatRoom implements ChatMediator {
    // 添加权限控制逻辑
    @Override
    public void sendMessage(String msg, User sender) {
        if(!checkPermission(sender)) {
            sender.receive("错误：您已被禁言");
            return;
        }
        
        // 消息内容过滤
        String filteredMsg = filterSensitiveWords(msg);
        
        for(User u : users) {
            if(u != sender) {
                u.receive(filteredMsg);
            }
        }
    }
}

3.2 消息类型分流

通过中介者实现不同类型的消息处理策略：

java复制void sendMessage(String msg, User sender, MessageType type) {
    switch(type) {
        case TEXT:
            processText(msg, sender);
            break;
        case IMAGE:
            processImage(msg, sender);
            break;
        case FILE:
            processFile(msg, sender);
            break;
    }
}

3.3 用户状态管理

利用中介者维护全局用户状态：

java复制private Map<User, Boolean> onlineStatus = new ConcurrentHashMap<>();

public void userLogin(User user) {
    onlineStatus.put(user, true);
    broadcastSystemMsg(user.name + " 上线了");
}

public void userLogout(User user) {
    onlineStatus.put(user, false);
    broadcastSystemMsg(user.name + " 下线了");
}

4. 性能优化与生产级实现

4.1 线程安全方案

生产环境必须考虑并发场景：

java复制// 使用CopyOnWriteArrayList避免遍历时的并发修改异常
private List<User> users = new CopyOnWriteArrayList<>();

@Override
public void sendMessage(String msg, User sender) {
    // 并行流提升广播效率
    users.parallelStream()
         .filter(u -> u != sender)
         .forEach(u -> u.receive(msg));
}

4.2 消息队列集成

高并发场景建议引入消息队列：

java复制// 使用Redis发布订阅
public void sendMessage(String msg, User sender) {
    redisTemplate.convertAndSend("chatroom.channel", 
        new ChatMessage(sender.id, msg));
}

// 订阅端处理
@RedisListener(channel = "chatroom.channel")
public void onMessage(ChatMessage msg) {
    // 分发逻辑...
}

4.3 流量控制策略

防止恶意用户刷屏：

java复制private RateLimiter rateLimiter = RateLimiter.create(10.0); // 每秒10条

public void sendMessage(String msg, User sender) {
    if(!rateLimiter.tryAcquire()) {
        sender.receive("消息发送过于频繁");
        return;
    }
    // 正常处理...
}

5. 实战踩坑记录

5.1 循环引用问题

错误示范：

java复制// 在中介者中直接持有用户对象引用
class BadMediator {
    private User user1;
    private User user2;
    // ...
}

这会导致内存泄漏！正确的做法是使用弱引用或唯一标识符关联

5.2 过度中心化陷阱

中介者不应成为上帝对象：

java复制// 错误：把所有业务逻辑都塞进中介者
class GodMediator {
    void handleMessage() {}
    void manageConnection() {}
    void processPayment() {}  // 违反单一职责原则
    // ...
}

解决方案：按职责拆分多个中介者，或结合其他模式如责任链

5.3 分布式系统挑战

跨节点通信的解决方案：

1. 采用全局唯一消息ID防止重复
2. 使用一致性哈希分配中介者实例
3. 最终一致性保证在线状态同步

java复制// 分布式锁示例
public void sendMessage(String msg, User sender) {
    String lockKey = "msg_lock:" + sender.id;
    try {
        if(redisLock.tryLock(lockKey, 10, TimeUnit.SECONDS)) {
            // 处理消息
        }
    } finally {
        redisLock.unlock(lockKey);
    }
}

6. 测试策略与验证要点

6.1 单元测试重点

java复制@Test
void testMessageBroadcast() {
    TestMediator mediator = new TestMediator();
    User user1 = new ChatUser(mediator, "User1");
    User user2 = new ChatUser(mediator, "User2");
    
    mediator.addUser(user1);
    mediator.addUser(user2);
    
    user1.send("Hello");
    
    assertEquals("Hello", user2.getLastMessage());
    assertNull(user1.getLastMessage()); // 自己不接收
}

6.2 性能测试指标

1. 消息延迟：从send()到receive()的时间差
2. 吞吐量：每秒处理消息数
3. 内存占用：万级用户在线时的内存消耗

6.3 混沌工程实验

模拟以下异常场景：

• 中介者进程崩溃
• 网络分区发生时
• 消息积压超过队列容量
• 恶意用户发送超长消息

7. 架构演进建议

7.1 微服务化改造

将聊天室中介者拆分为独立服务：

code复制chat-service
├── mediator-core   # 核心中介逻辑
├── gateway         # 协议适配
├── storage         # 消息持久化
└── push-service    # 实时推送

7.2 插件化扩展

通过SPI机制支持功能扩展：

java复制interface ChatPlugin {
    void beforeSend(MessageContext ctx);
    void afterReceive(MessageContext ctx);
}

// 实现敏感词过滤插件
class SensitiveWordPlugin implements ChatPlugin {
    @Override
    public void beforeSend(MessageContext ctx) {
        ctx.setMessage(filter(ctx.getMessage()));
    }
}

7.3 流量分级策略

根据消息优先级差异化处理：

java复制enum MessagePriority {
    REAL_TIME,    // 即时消息，优先处理
    NORMAL,       // 普通消息
    BATCH         // 批量消息，可延迟
}

public void sendMessage(Message msg) {
    switch(msg.getPriority()) {
        case REAL_TIME:
            realTimeQueue.add(msg);
            break;
        // ...
    }
}

在真实项目迭代中，我建议先用中介者模式实现核心消息通路，再逐步添加高级功能。切忌一开始就设计过度复杂的架构，这反而会失去中介者模式简化对象交互的初衷。