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表现