qq_36790074的博客

任务条件设计

wrk 压测

除了固定轮训消息，可能出现一些特定情况下的轮训消息，比如比赛结束，晋级信息等，客户端也不知道什么时候服务器计算出结果，可能服务器也不知道 -_-, 这样的就会导致类似这样的消息，也变成固定轮训，严重浪费资源。根据测试可以发现，客户端按现有频率，同时可能产生多个连接（客户端并发发送所有待发送协议），高峰时最多可占用7个服务器连接，正常情况下占用2个服务器连接，其实这样的情景已经不适合用短连接了，但是改成这个方案，可以有效的减少代码的改动，提高整体效率。这样的方案，不管，服务器是什么网络模型，都可以正常处理。

申请添加好友的人，动态的修改好友的数据,当然好友在线的话，可以给好友发一条消息，好友在线修改添加，如果离线，我们采取的方案是直接给这个好友添加数据（注意理论上这里会出现，玩家A修改玩家B的数据，玩家B此时刚好上线获取，发现拿的是老数据，导致数据错误），不过这个问题没有被提出来，是后面我自己分析出来了，后面跟做的人说，他感觉这个问题先这样，我相信大家都碰到过这种情况 ^ ^。这种设置可以只修改自己的数据，黑名单可以直接在表里体现，申请状态也可以直接在表里体现，可结合业务情况设计“好友申请”、“黑名单”功能。

另外，玩家上线后会获取很多数据，只是提示作用，获取完整的数据效率低，大部分情况没有实际意义，使用红点可以很好的解决这个问题，玩家上线时只推送一个数组，表示各个系统的红点状况，如果玩家需要深入查看，则获取详细的信息。一般来说项目前期，基本不会关注红点提示问题，后期提了需求后，做了一部分发现，每做一个模块都需要添加一个协议，不如设计一个系统统一管理这个问题；

奖励Reward系统设计

这个基本和系统邮件类似，就是奖励的获取建议，建议使用一个至少为byte的字段GotSign表示，如果后期存在 部分领取的情况，将这个字段分成几位，每一位代表奖励的领取情况即可。2.尽量不存储重复信息，比如同步的系统邮件，如果内容固定，个人邮件只需根据MailId即可获取邮件的内容，数据库不用再存储相关的内容字段，当然也要结合实际业务。1.直接获取全部的邮件内容，邮件数目多的时候会比较费，如果可以合理的控制邮件的过期时间，这个方案是可以的。所有人都可以接收的邮件，一般系统发放后，玩家登录时拉取。

这个主要是设置相关的业务触发类型，不同的业务设置不同的值，这里建议将类型至少设置为ushort, 太小后期会出问题 ^ ^这里建议将状态的枚举值设置的大一些，方便后期插入一些特殊的状态，要不然需要改许多已经写好的东西，踩过坑的都懂的为啥 ^ ^一般来说，当任务结束，也就是相应的条件完成，比如常见的主线、支线、每日、每周、委托、成就任务等。激活任务的条件id列表，满足则任务进入 Active 状态，否则 处于 Init 状态。完成或改变特定的条件，触发任务状态的改变，一般由各个系统触发；

经常会有许多活动、或则任务、当用户完成后，可以获得相关的奖励，当然可以是提前定死的几个、但如果想要 产出不同的 奖励的话，给每个物件配置相关的权重，就可以实现。之前在阿里的 负载均衡 比赛中，就有这个算法，RocketMQ 中包含多种负载算法，其中 权重 算法就属于其中一种，也是最实用的一种。weight 属于 (10,30] => index = 1。weight 属于 (30,40] => index = 2。weight 属于 (0,10] => index = 0。

/**5896. 股票价格波动给你一支股票价格的数据流。数据流中每一条记录包含一个 时间戳 和该时间点股票对应的 价格 。不巧的是，由于股票市场内在的波动性，股票价格记录可能不是按时间顺序到来的。某些情况下，有的记录可能是错的。如果两个有相同时间戳的记录出现在数据流中，前一条记录视为错误记录，后出现的记录 更正 前一条错误的记录。请你设计一个算法，实现：更新 股票在某一时间戳的股票价格，如果有之前同一时间戳的价格，这一操作将 更正 之前的错误价格。找到当前记录里 最新股票价格 。最新股票.