14 代电池是最拉的。。。

在飞猪找签证办理，问商家就行。

阿里云 serverless 函数计算

@kaiki 还收藏过 20 年前的水浒卡到现在，也是入行 20 年有超百件藏品的资深收藏家了

找副总聊聊诶 表表衷心 你不搞关系还搞事，你跟经理关系都不近还说人家下面的人能力不行，不搞你搞谁啊。。。
现在新来的没有过试用期，还有机会。

@banmuyutian 242https://i.imgur.com/L62ZP7V.png

@shrimpDumpling #10 啥模型生成的，很棒棒啊

解梦：在真实的战场环境中第一步就是切断所在地区的通信，假设场景成立，诺基亚一定处于无服务状态，无论你如何调用接口都无法达成目的，最终导致战成溃败成了罪人，梦境对应现实工作中就是由于疏忽没有设计备用方案酿成大祸，影响程度已经达到可以随时会让 op 卷铺盖走人的程度，甚至还要让 op 的房子卖掉赔偿公司损失（对应去山姆找睡袋买帐篷，对应睡大街已无安身之所）。

支付 10 元听详解 https://i.imgur.com/L62ZP7V.png

@rqxiao mysql 在这个场景更容易理解毕竟是肯定持久化的业务，可以查查 io wait 对 mysql 的影响，相关文档更好找也更容易理解。

@rqxiao 先说结论我用过的高负载 mq 没有一个开启持久化，redis 也是有 AOF 对吧，你们会开吗？
就算有磁盘持久化也只是另外的程序去异步刷盘，不会是运行一个命令就往磁盘写一次，肯定是每隔一段时间进行一次刷盘操作，道理是通用的，那一旦崩掉重启必然是丢失未刷盘的数据，因为你要从磁盘恢复数据。
mq 默认的刷盘时间是 25ms ，在高并发时期，大量推和大量消费，在海量数据持续刷盘的过程中势必产生额外的 cpu 开销，同时你还得保证你的磁盘 io 一定够用，不然潜在丢失的数据会更多。所以高并发肯定是不开启持久化。

既然在高负载时期崩掉必然会丢失数据，那么从调用 mq 前起码你应该入库以在崩溃时保证数据本身不会彻底丢失，这是最底线，所以也必然有修复丢失数据的机制，消息本身通常是某个微服务的处理结果，也就是说丢失数据本身只是影响的数据的实时性不可能因为 mq 崩溃导致整个系统链路彻底挂掉，消费设计有幂等可以保证上游系统重推也能有数据一致性。在架构设计完整的情况下，我们是不是应该把有限的资源给到关键的队列计算而不是刷盘这种备用方案，我需要的是它不挂而不是挂了尽量少丢数据。这个技术选型的目的就是极致的实时性，挂了就按照各自的业务走备用方案回溯。

@Removable 掉小珍珠了吗

你不是在摸鱼吗，老板已经亏冒烟了

只能说废了，就算不酒驾，光赌这一条已经结束了，后面就是输急眼了借钱干压几年工资。
越陷越深，买定位没有任何价值，你妈去抓他回来只会影响夫妻关系，实质上影响不了他的行为，今天不去还有明天。
最稳妥的就是离婚，让他净身出户，随便赌 随便喝出事了不要连累家人。

@a1oyss0925 #11 kafka 上了 serverless 版本真的屌的飞起 最低配一个小时推几十亿真的洒洒水

我来解释一下吧，这个题属于答不出来没啥，答出来有惊喜
最核心的区别
Kafka 是磁盘存储 消息延迟相对高 但可以承受大量的消息囤积 吞吐量超大 并且支持批量处理
通常应用于大数据/写日志/前端埋点上报等等对消费延迟不敏感但量大的业务，更适合一般业务。

RabbitMQ 是内存存储 延迟极低 因为内存容量问题不能承受大量消息囤积，适合实时性高的快速消费业务
通常应用于订单流转/广告上报，必须要开启足够多的冗余消费者还要保证消费的快速不阻塞，对监控要求极高，打满就挂了，更适合高实时性的分发类业务还可以 exchange 由一个队列分发到 n 个队列不同微服务分别消费。

orbstack 啊。。。。

不要用使用 24 小时放到无线充电上 就掉的很快

独立思考一下
假设是真的，那也是银行允许范围，即然允许就是公开途径，这 4000 就是给人家白赚的信息差价。
假设是假的，那就是诈骗。