iOS 点赞功能高并发的思考-CSDN博客

前言

微博上热点的点赞数数W。服务器遇到这么高并发请求压力肯定很大。数据库要怎么写入这些点赞就不探究了（真是个大工程，如果每接收一条就写入一次），只探究iOS手机端怎么处理点赞功能。

本文将参考微信和微博，猜测其实现，并探究如何处理点赞功能。

微信朋友圈的点赞数相对来说少。微博的点赞数能达五位数。其应该采用了不同的策略。

先从宏观上思考这个问题。

分为两类 什么时候获取服务器最新点赞数 点赞按钮与网络的交互

手机端不会对每一条消息实时跟踪点赞数，在某些情景下才会请求数据（进入详情页等）。
如果每次点击 点赞/取消点赞 按钮，就发送一次请求，用户期望是最后一次操作的效果。但是若遇到网络问题，最终写入数据库的值就无法控制了。那么按钮事件应该如何处理呢？

什么时候获取服务器最新点赞

先研究微博

对于别人的微博。可以看到一开始是采用本地存储的赞数，点进去详情页后才会向网络获取一次点赞数，并且更新本地存储的。（仅发起一次）

针对自己发的微博就不研究了，万年不发一条微博，印象中是收到点赞会收到推送的。
再研究微信
1. 打开朋友圈，先用本地的数据，但是当滑动到某一条别人发的朋友圈时。如果有新的赞，会显示出来（有延迟，应该是网络请求滞后）。
2. 再来看自己发的朋友圈，收到点赞红点后，滑动下去发现这个赞就躺在那了，无延迟。如果视图锁定在自己发的朋友圈内（如下图），点赞也会更新，因为有收到红点动态。即收到红点动态的时候，也会获得点赞信息，有必要的话刷新UI。别人对自己发的朋友圈首次点赞?
3. 对第二点再深入点。自己发的朋友圈，如果某个人点了赞，查看完红点后，这个人取消->再次点赞。微信不会显示红点。换言之，不属于新动态。
4. 点了别人的赞后，该条朋友圈有新动态也会刷新点赞信息。
5. 点进详情页必定会刷新。
所以大胆猜测，对自己跟踪的朋友圈，会有个特殊的API获知哪一条朋友圈的新动态。该API可能采用定时访问，偶尔就访问一次；听杜优秀说可能是socket或者protobuf这种高速的http请求。
总结
1. 滑到cell处对该cell进行刷新（一次）。
2. 采用一个特殊的API，获取跟踪的新信息。
3. 进详情页必定获取一次最新点赞信息。

当然具体的情形远比这复杂，以上也就是个人瞎猜的。

点赞按钮与网络的交互

由于网络的不稳定性 以及 用户可能随时关闭App导致未成功发出请求，用户期望的点赞状态与数据库的数据无论如何也不能保证一定一致。

但是如何尽可能地实现一致呢？针对这个问题提出个人的愚见。

还是先从微信和微博入手思考。

无网状态下

微博UI不变状态，当然也不发出请求。

微信UI有点赞效果

一开始是没有点赞的，最终UI设为点赞。

顺便说说结果，连上网后详情页发现确实设了点赞。

但是如果关闭微信，再打开，会发现点赞不见了。

很差的网络状态下

2G网络实测，三条微博从无点赞状态按了好几次点赞又取消，退出App连4G后打开看服务器的状态，发现有些点了赞，有些没有。即难以确定。

2G网络实测，微信点赞后取消点赞，UI突然变成点赞状态了。应该是请求成功后刷新本地数据和UI。

如何实现比较合理

以下纯属个人愚见，如果有更好的实现方法，欢迎大佬提出来。

首先是 UI如何显示

先说个简单万能的方法。

有时候，用户有意识发起的网络请求，我们都会显示“加载中”甚至不让用户点击。然后在请求成功处理数据完成后，再让用户点击。例如登录界面，点击登录后，我们会显示"登录中"，并且禁止用户进行其他操作。类比着，点赞后，不让用户进行其他操作，显示“发起请求中”。成功就更换按钮状态，失败提示"点赞失败/取消点赞失败"。这样虽然能完全避免高并发以及期望值不一样但用户不知道的情况。

然而，这种方法用户体验并不好。但是如果选择了用户体验，带来的问题是用户或许无聊会一直点按钮，高并发请求，对手机内存和服务器都造成了巨大压力。也有可能最后写入服务器的数据并不是用户期望值。但主流App都会为了用户体验，承担这些后果。

所以除了在服务器那加进处理外，手机端也有必要减少高并发的压力。

在这我更倾向于微信的做法，让按钮二级view显示，这就减少了用户误点赞后取消点赞的可能。而且也给了时间完成网络请求。

还有一种想法是，先让UI更改，请求失败就改回去，并且提示“请求失败”。微信里会小红点提示“点赞未发送”。应该是类似的。

然后是什么时候要发起网络请求

微博那个我并没有看懂，有网情况下，每次点击都会发起请求，然后随缘看最后一次的结果吗？

微信的点赞请求应该是马上发出的，但取消点赞很难说。因为2G时，点赞后马上取消点赞，最终结果却是点赞。

每次点击都发送是最容易造成高并发和期望值偏差 的操作。所以不建议每次点击都发送这种随缘法。

方法一

猜测微信里应该是更改第一次请求，请求期间点击按钮都只是更改个样子看看，并且请求成功后刷新本地数据和UI。然后才允许下一次请求。

那么就会有一个问题，微博上刚刚发送点赞请求，然后又点进了详情页。所以在点跳转之前判断，没有请求完成就在详情控制器中注册了一个通知。当请求成功后，发送通知，通知详情控制器刷新数据。

猜测代码如下

NSMutableArray *isRequestingArray;//保存每一个cell 是否在发起网络请求的BOOL

- (void)btnClick:(UIButton *)btn atIndexPath:(NSIndexPath *)indexPath {
    // 更改btn的样子
    btn.selected = !btn.selected; 
    // 还要修改本地的数据 点击进详情页要看到状态变了
    // 最后根据判断发起网络请求
    if (![_isRequestingArray[indexPath.section][indexPath.row] boolValue]) { // 无其他请求
        //设置正在请求
        _isRequestingArray[indexPath.section][indexPath.row] = @"1"; 
        __weak typeof(self) wself = self；
        [PraiseAPI startWithSuccessBlock:^(__kindof BaseRequest *request){
            __strong typeof(wself) sself = wself;
            sself->isRequestingArray[indexPath.section][indexPath.row] = @"0";
            // 更改btn的样子
            // 修改本地的数据
            // 发送通知
        } failureBlock:^(__kindof BaseRequest *request, NSError *error) {
            __strong typeof(wself) sself = wself;
            sself->isRequestingArray[indexPath.section][indexPath.row] = @"0";
            // 恢复btn的样子
        }];
    }
}

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    NextViewcontroller *nextVC = [[NextViewcontroller alloc] init];
    if ([_isRequestingArray[indexPath.section][indexPath.row] boolValue]) {
        //正在请求  nextVC添加通知
    }
    [self.navigationController pushViewController:nextVC animated:YES];
}
复制代码