基于.NET Core与MS-SQL的客户端位置共享后端高并发优化方案咨询

数据老陈

2026-4-29

好问题！你的初始轮询方案在百万用户量级下确实会遇到毁灭性的性能瓶颈，WebSocket方向是对的，但结合.NET Core生态，还有更成熟的落地思路，我来给你拆解几个可行的方案：

首推方案：使用.NET Core SignalR实时通信框架

SignalR是微软官方为.NET生态打造的实时通信库，它会自动根据客户端环境在WebSocket、Server-Sent Events、长轮询之间切换最优传输方式，比手动实现WebSocket稳定得多，还内置了用户标识、分组管理等核心功能，完美适配你的位置共享场景：

位置上报优化：用户通过SignalR建立连接后，每2秒发送坐标到服务器。服务器不需要立刻写入MS-SQL，而是先把数据存入Redis缓存（用Hash结构存储用户ID和坐标的映射），再通过后台定时任务（比如每10秒）批量异步插入数据库——这能把数据库的写入请求量从每秒50万次降到每秒10万次以内，直接缓解数据库压力。
按需推送替代轮询：当用户2需要查看用户1的位置时，让用户2调用SignalR的分组订阅接口，加入用户1的专属分组。服务器只需要把Redis里的最新坐标推送给该分组的订阅者，而不是让用户2反复拉取。这样只有真正关注目标用户的客户端才会收到数据，彻底消除无效请求。

举个简单的SignalR Hub示例：

public class LocationHub : Hub
{
    private readonly IDatabase _redisDb;

    public LocationHub(IConnectionMultiplexer redis)
    {
        _redisDb = redis.GetDatabase();
    }

    // 用户上报位置
    public async Task UpdateUserLocation(string userId, double x, double y)
    {
        // 缓存到Redis
        var location = JsonSerializer.Serialize(new { X = x, Y = y });
        await _redisDb.HashSetAsync("live_user_locations", userId, location);
        
        // 推送给所有订阅该用户的客户端
        await Clients.Group($"user_{userId}").SendAsync("ReceiveUpdatedLocation", userId, x, y);
    }

    // 用户订阅目标用户的位置
    public async Task SubscribeToUser(string targetUserId)
    {
        await Groups.AddToGroupAsync(Context.ConnectionId, $"user_{targetUserId}");
        
        // 先推送一次当前最新位置（避免订阅后等待2秒）
        var cachedLocation = await _redisDb.HashGetAsync("live_user_locations", targetUserId);
        if (!string.IsNullOrEmpty(cachedLocation))
        {
            var location = JsonSerializer.Deserialize<(double X, double Y)>(cachedLocation);
            await Clients.Caller.SendAsync("ReceiveUpdatedLocation", targetUserId, location.X, location.Y);
        }
    }
}

手动实现WebSocket的优化要点（如果不想用SignalR）

如果你坚持自己封装WebSocket，一定要注意这几个关键优化点，否则百万级连接会直接压垮服务器：

线程安全的连接管理：用ConcurrentDictionary<string, WebSocket>维护用户ID和连接的映射，避免多线程下的冲突。
批量异步写入数据库：用Channel<T>创建内存队列缓存上报的位置数据，后台开启一个独立任务批量读取队列并插入数据库，不要收到一条数据就写一次库。
惰性推送逻辑：只有当有其他用户订阅该用户的位置时，才维持推送通道；如果没人订阅，甚至可以暂时降低该用户的上报频率（比如改成每10秒一次），或者只缓存数据不推送。

进阶架构优化（应对超大规模用户）

如果你的用户量还会持续增长，可以考虑这些架构层面的优化：

Redis发布/订阅解耦：用户上报坐标时，直接发布到Redis的对应频道，推送服务监听频道消息并转发给订阅的客户端，应用服务器只做消息转发，不处理业务逻辑，进一步降低服务器压力。
微服务拆分：把位置上报服务、推送服务、数据持久化服务拆分成独立的微服务，分别扩容不同的节点——比如上报服务需要更多的连接处理能力，就多扩容上报节点；推送服务需要更多的消息转发能力，就多扩容推送节点。
地理位置分区：如果用户是按地域聚集的（比如同城用户互相查看位置），可以把用户按区域划分到不同的服务器集群，减少跨集群的消息转发，提升整体性能。

一定要避开的坑

不要让所有用户都维持WebSocket连接却没有实际推送需求，这会浪费大量的服务器连接资源，必须做惰性订阅——只有当有人查看时才建立推送关系。
绝对不要同步写入数据库，异步批量处理是应对高频写入的核心手段，否则百万级的写入请求会直接打垮MS-SQL。

内容的提问来源于stack exchange，提问作者Jatin