@wangxiaoaer #15 你知道你这最不通在哪么，世界不是静态的，个人有个人的合理需求，最终就是个博弈结果，觉得理所当然真的毫无意义

logstash

@fivee #7 9 楼说的对，既然你想要好的服务，你干嘛不直接和商家说我加钱你给我发顺丰，商家是有责任确保货物正常到你手中，但是他并没有无限责任要提供最好服务，再说客户也不是上帝，现在的服务标准是动态选择大多数人能接受的结果，并不是天经地义的，你想要更好的服务就加钱呗

关于万一恰好是比自己等级高的，这更不用想啊，看看动物世界，一只蚊子傻乎乎的跑到一只青蛙面前扯淡，你说啥结果，这种显而易见的事情不直接写出来也很正常吧，再说作为观察者 A 人家派出几百上千战舰，有几个有点蠢又运气差的也不影响自己不是

似乎楼主认真看了不，首先能观察的都必须是完成曲率航行的二级以上的星际文明，不是地球人这种太阳系都出不去的，只有被观察被灭的份，其次 A 观察者是开着战舰满星系飞来找的，书中应该没说人家蠢的直接在自己星球上架个望远镜来看吧，看完打完就跑你即不知道它从哪来也不知道它去哪了，如何会暴露他自己

为啥老是往一边歪，陀螺仪没放正么😂😂

都微服务了，肯定不允许跨服务表 join ，关联数据那不就是正常的数据加载么，如果真的有需要聚合查询，那么聚合查询也是一个微服务，按业务流程汇流数据到自己这然后再对外提供服务

审计日志那就要看你要的是哪种了，审计日志一般说的是后台操作日志吧，那么网关完成鉴权后完成请求之后写操作日志就可以了啊，毕竟要求记录的是操作日志，和服务请求日志是两回事，并不需要记录整个链路，既浪费资源也用处不大，服务日志也会按请求日志、链路追踪日志、纯文本自己再代码里写的各种七七八八的日志、性能状态日志都各有各的要求，所以都是要单独处理的，一般来说可以把链路追踪日志和请求日志合并记录会方便很多

@huangya #9 如果是这样，那么中断产生条件可能是队列非空，或者你看的这个可能是系统软中断，网卡处理数据正常都是硬中断触发软中断，读取解析数据的过程一般都会在软中断中完成，并不会直接在网卡硬件中断中直接开始处理数据

@huangya #4 一般来说，正常做这个中断程序干完屏蔽中断之后，都是循环读取直到缓冲区读取完成，然后解除屏蔽中断才结束的，正常情况下应该都会把检查队列是否空和清除中断屏蔽设计成一个指令才对

法律本来就是有漏洞的，要是法律是完美无漏洞，那你现在只能遵守几千年前的法律了，完美的东西无法进步也需要进步

Android 的分应用代理其实底层是通过系统策略路由表实现的，把不需要的应用都设置为绕过流量就完全不经过 clash 了，剩下的没多少了吧，而且流量解析其实没多少计算量，系统提示耗电多估计是电量统计问题吧

所以不应该把日志自动汇总到统一的日志管理服务器么

bitmap 应该是数据量计算量都比较少的了吧，如果视频量比较多用户看的少，那么把 bitmap 分区就是了呗，整区都没看过就不需要保存，redis 就有 bitmap 支持，或者保存在数据库也行啊，分区后用视频 ID 直接就可以计算分区号，然后用区块号读取整个区块很快就判断完了，如果是信息流这种用户看过的和即将看的都是最近的，那么读取数据量还是很小的

@guowq #17 人家那叫每周发版，不是每周一个版本，固定发布周期而不是固定开发周期，很多团队很多功能同时开发，本周啥功能完成发啥，但每个功能周期不定，最近不这么干了，估计是公司砍预算估计也没那么多功能要开发了

CICD 、金丝雀环境、灰度环境搞起来会方便不少，而且不要把发布周期和产品功能版本周期合在一起，要快速滚动就需要产品功能需求碎片化，每个功能的开发测试周期本身还是按功能复杂度来的，硬要开发周期也对齐两周那真是坑死自己了

@Mindzy #21 政策市也得有资金有信心有市场啊，这种行情没政策就要一直跌了，有政策顶多能撑住

@Mindzy #11 你太乐观了吧，最近只是信息有所恢复吧，科创板有些回调也纯属前面跌太狠了，但科技企业的估值和全球平均利率关系非常大

@ladypxy #7 看来是买在了本轮周期的高点，看目前这进度估计明年后年都解套希望不大啊，好消息是估计下方空间也不大了。。。

#3 楼说的是对的，这事重点不在于卷不卷高考，重点在于学习和教育自古就是艰苦的，如果你觉得真的可以让孩子可以快乐学习日后还能自己有所成就，那铁定是妄想，漫长大量的知识积累和重复累赘的训练必不可少，参不参加高考不重要怎么参加才重要，而且心存侥幸三心二意才是不可取，当然如果你家境实在优厚选择多或者你孩子确实是天才，那自然不在此列了