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

https://github.com/donnemartin/system-design-primer

把系统设计读明白，再问架构设计的问题都不慌了。

@Tyrant1984 感谢大佬解惑！

香港的服务业已经是粪坑了，国内哪个 1 、2 线城市的服务业不吊打香港？香港本地人都受不了本地的服务业了，来深圳旅游了。

手机通过 AI 算法进一步积压了相机的生存空间，手机镜头不行，但是算法优化的好啊。

相机以后注定是小众玩家的爱好了，小众玩家的产品价格肯定要涨的。

不好意思把标题读成了:

逆天！干! 3 年的同事用 XXXX

这不是指定了 798 的秦吗。。。

@drymonfidelia 客户端从上面的报错信息看线程池还有很大空闲

你的报错信息展示的都是.net 的线程池信息，并没有 redis 服务端的监控信息。

1.不要换成 Sub/Pub,性能上不会有提升，架构更复杂了。
2.提高 redis 的超时时间。

redis 的 client 超时时间可能是全局线程池繁忙导致的，也可以是 redis 服务端导致的。redis 可以加一下监控，看有没有大 key/热 key 查询。

await redis.GetDatabase().LockTakeAsync($"PlaceOrder:{user.UserId}", "1", TimeSpan.FromSeconds(180))

你这个是获取 redis 锁吧。如果方法返回的 true ，则获取到锁；反之，则循环获取锁。在循环里等待 1ms ，这个是不是太短了。

https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.delay?view=net-8.0#system-threading-tasks-task-delay(system-int32)

最近在用 rust 造轮子，
网关:https://github.com/lsk569937453/silverwind
redis:https://github.com/lsk569937453/rcache
echo-server:https://github.com/lsk569937453/echo-server
curl：正在造

总结:欲造轮子，起码得先把原有的技术架构/源码搞懂，es 这种复杂的等大神吧

建议换赛道(重学 java/golang)，或者努努力学下 solana 搞 web3 ，其他的 rust 职位根本不好找。

Spring 用倦了，公司的容器资源寸土寸金，一个项目启动后容器占用 2G 内存，快吐了。

一看就是工作一两年的新手，还想着硬件上给公司省钱啊。。。。老油条从来就是什么手熟用什么框架，至于硬件资源，那是公司的问题，不是你的问题。

@cfeitong 已经测试了，结果在这里 https://v2ex.com/t/1031987#reply5 。

grpc 的 protobuf 比 json 啥的占用空间小，传输速度快。所以对性能要求很高的可以用 grpc,其他的 Feign( http 协议+json)就可以了。

@bug123 rcache 和 redis 的机器配置都是 4 核 8G 。
实验中 redis-benchmark 的请求数是 10 万，16 线程。
当请求数为 10 万，线程数为 16 时，rcache 的 cpu 使用率 115%,吞吐量为 20 万。redis 的使用率为 70%，吞吐量 10 万。
当请求数为 100 万，线程数为 16 时，rcache 的 cpu 使用率 380%,吞吐量为 33 万。redis 的使用率为 100%，吞吐量 11 万。

@loszhang 肯定是异步记录。用户发起 1000 笔运单支付请求后，前端直接展示"运单支付处理中，完成后将会发送短信通知，在此期间请不要重新提交新的运单支付。"就完事了。

在用户的 1000 笔运单处理过程中，不允许用户再次提交另外的 1000 笔运单支付。这样是最简单的。

@JingXiao 我对屏幕这个不感冒，主要是看小说和打王者，感觉不出好坏来。