@guanzhangzhang 这 terminal ui 库学起来头疼，算了。

昨天手撸了一个，100 行代码而已。目前卡在了 cli 查看历史监控这里，数据已经存储在 sqlite ，查询的时候不知道用什么展示好点。

ApiGateway--https://github.com/lsk569937453/silverwind
Rcache(Reimplement the redis in rust)--https://github.com/lsk569937453/rcache
Rcurl(Reimplement the curl in rust)--https://github.com/lsk569937453/rcurl
KT(Impelemet the http load testing in rust)--https://github.com/lsk569937453/loadTesting

@proxyai
rust 不是银弹。
我在用 rust 实现 redis 的过程中对比了 mpsc::channel 和 Arc::Mutex 的性能。
单线程下，两者性能差不多的。
多线程下，全局 Arc::Mutex 对数据加锁的性能还比 mpsc::channel(多生产者单消费者)好一点

https://github.com/lsk569937453/rcache/tree/main:全局锁
https://github.com/lsk569937453/rcache/tree/0.0.1:mpsc::channel 实现的多生产者单消费者模型

java 的类库这么多，找一个符合你要求的就可以了。

直接 window 开发，然后部署到 linux 上就可以了。

去哪儿的 app 首页有二十多个接口。

axum+1

@veapon 有什么就说什么，如果你不懂可以不说。做技术的不要拿反问句回答别人。

@veapon 请问我创建线程的时候获取锁耗时 1ms 。而你往阻塞队列塞任务不需要锁，但你任务入队了又不能执行，所以你讨论耗时有什么用呢。

@orzwalker111 我使用线程池当然是通过并发让任务快速执行。难道除了"让任务快速提交执行"之外还有其他的选项吗？

@codegenerator
```
先创建线程如果线程执行完任务就会空闲，空闲等待一定时间就会销毁
这样会有比较多的线程创建销毁
```
既然你喜欢举例，那我就举一个例子。

我们假设线程池的前 n 个任务非常耗时，一直执行不完
"先判断任务队列是否满再判断是否达到最大线程数":如果任务队列长度是 10w ，那么后续提交的 10w 个任务(执行耗时很短)，在任务对列满之前无法执行，需要一直等待在队列中。

结论:大聪明。你完蛋了，准备提桶跑路吧。

如果我的老大给我提个需求要换个框架重构，我都要自己跑路。你还自己提出来，这就是挖坑给自己跳。我自己碰到现实中不得不重构的原因:
1.新来的领导换技术栈，招自己心腹来，把老员工排挤走。
2.公司合并，老的组离职了，老代码维护不了，线上频繁出问题，需要重构。

说下为啥不推荐超大项目重构的原因：
1.重构期间还接新需求吗，你这 700 个接口大概率半年是搞不完的。这半年期间，你不接新需求了吗？如果一边接新需求一半重构肯定对重构进度/接新需求进度有影响(否则就需要招人来做，你和老板说我自己干不过来，那你提重构搞毛啊)。
2.越大的项目需要的回归测试周期越长，有的代码单元测试都没有，就是黑盒。只要这 700 个接口有一个重要接口重构有问题，你就得负责背锅。
3.腾讯的 QQ 重构的时候都会出问题，你是不是觉得你比腾讯的工程师还 6 。

再说下重构的方案:
1.先把当前受影响的接口重构(你生产环境跑的好好的，没有问题。重构就是自己找罪受)
2.不重构，新需求直接上 springboot 那一套。

https://github.com/lsk569937453/rcache

用 rust 实现的 redis ，用 redis-benchmark 测试，4 核 8G 下，rcache 的 tps 是 redis 的两倍。我这还是简单的直接用全局锁一个 Map ，不知道 garnet 用的什么黑科技。

缺点就是 rcache 多线程下 cpu 几乎能跑满，而 redis 的 cpu 一直稳定在 100%左右(这就是单线程的魅力吗。。。)

@iqoo 就是类似 wrk 和 apache jemeter 的 http 测试工具。

1.秒杀直接上 redis ，把课程 Id 和对应的数量放到 redis 里，抢到后往消息队列发消息，然后通过消费者处理后续的流程。
2.redis 满了之后可以设置过期策略。把策略设置一下就好。
3.这是扩展题。发现性能瓶颈，然后通过削峰、限流、扩容、分表等手段让系统平稳的处理流量。