[TOC]
- 可以对一个对象(一条feed、文章、或者url)进行 like 操作,禁止 like 两次,第二次 like 返回错误码
- 有 isLike 接口,返回参数指定的对象有没有被当前用户 like 过
- 需要看到一个对象的 like 计数
- 可以看到一个对象的 like 用户列表(类似 QQ 空间);
- 上述列表加分项:Like优先显示我的好友列表(social list)。
- 数据量:每天新增的 like 对象数为 1 千万,每秒 like 计数器查询量为 30 万次 / 秒。
- 用户数量级1亿,好友数量级1~1万,单个对象的Like数量1-100万
- 提供比赛数据集(纯文本格式),需要参赛人员自行导入到自己数据库
- 建议用关系数据库持久化,关系数据库可自行部署在主机上
- 技术栈及编程语言不限制
- 一共3台云主机,不使用云数据库
- 部署方式不限
- 分布式或单体应用不限
- 选手需要完成规定的 HTTP API
- 评委使用统一的压测工具进行压测(自动适配 HTTP Keep-Alive)
- 压测单台机器的 API,不能使用 Load balance 聚合多台机的 API 来作为比赛成绩,也就是说主要业务逻辑应在被压测的机器完成,但是缓存、存储或者调用的微服务可以部署在其他服务器
- 选手需要一定程度证明架构的线性扩展能力,比如压测3台服务器,应该可以得到压测1台x3的结果。
- 性能分数 60 + 架构设计 40
- 取所有评委平均分
- 有架构设计文档或者方便评委理解的展示材料;
- RESTful 接口,压测数据;
- 最好有优缺点分析,说明权衡点;
server_ip/pcc?action=like|is_like|count|list&oid=xxx&uid=xxx
返回结果
"oid":1,
"uid":1,
"like_list":[{"1":"nickname"},{"2","Jerry"}]
}
like_list 返回当前对象的赞用户uid列表,只返回前 20 个用户即可
"oid":1,
"uid":2,
"is_like":1
}
"oid":1,
"count":1024
}
page_size: 返回的列表长度[uint8] is_friend: 是否仅返回只是好友的uid列表 cursor: 起始位置[uint64],取上次返回结果的next_cursor
"oid":1,
"like_list":[{"1":"nickname"},{"2","Jerry"}],
"next_cursor":1234
}
业务层面出现错误,实现者也需要返回HTTP 200,在返回结果body里面输出error code error code 由实现方自行定义
如
"error_code":501,
"error_message":"object already been liked.",
"oid":1,
"uid":1
}
测试数据下载:https://github.com/archnotes/PCC/tree/master/data (非压测数据)
uid为uint64,1亿条
1,Tom
2,Jerry
uid, friend_id为uint64,只存在双向好友关系,1亿个用户*1000,好友关系通常是一个长尾分布,90% 100个以下,8%长尾分布300-1000,2% 1000-10000
1,2
oid,uid为uint64,2亿个objects, 每个1-100w
101:[1,2,3,4,5]