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.