TL;DR
前言
这是一篇去年8月写的文章,本来是希望达到10k, 不过实际测试并没有成功,最终达到了1000+的事务,完成C10K的一个K,还有9个 :(
DB选择
| DB | 类型 | 业务 | io |
|---|---|---|---|
| Mysql | sql,支持事务,有缓存 | 强sql,强类型,类似java | B & B+ |
| Postgres | sql,支持事务 | ||
| Mongo | nosql,key-value DB,读很快 | 弱sql,非强制,类似js | B+ |
| Redis | nosql | just kv,代码复杂 | |
| sqlite3 | sql | 强sql,支持事务 | Btree |
初步结论,理论上是随便用,先用sqlite3把,如果性能达不到,再来排查原因和更改DB
业务场景
我们设计一个sticker网站,可以售卖sticker,用户可以购买sticker,sticker是有库存的,如果用户的余额足够,则可以售卖,另外售卖的过程中,如果库存没了的话,需要回滚订单。
主要对象
- 用户
- 商品,库存字段也在商品身上
- 订单
主要流程
- 商品的详情页面,get v1/api/sticker/:id
- 商品的点赞+1接口,post v1/api/sticker/likes
- 下单接口,post v1/api/order
- 订单查看接口,get v1/api/order/:id
表现
get 接口 读
load
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10154 ubuntu 20 0 1757000 36888 10020 R 362.7 0.1 2:48.41 main
9046 ubuntu 20 0 2125668 31976 9876 S 346.3 0.1 2:51.78 server
QPS表现