@SeleiXi #7 嗯嗯, 那就完全没问题了

> 然后因为 score 不会动态更新所以就想着用其他方案了

@SeleiXi 更新用 pipeline zrem+zad, 先删再重新添加, 就可以了 🤣

zset 足够了, timestamp 做 score, 没必要用其他的, 别想多了

> 要用键查询对应的值 & 知道前面还有多少个键值对是先于他创建且没有被删除的

zrank 查询对应的值的时候就会返回这个值的排序下标(整个 zset 排序下标从 0 开始), 默认 timestamp 升序, zrank 返回的值减 1 就知道前面有多少个是先于它了.
你保证每组操作原子性, 比如单次如果需要多个操作就 pipeline, 这样就能保证你每组操作在 redis 里是串行执行的, 所以你当前能查到的所有结果肯定就是对应的存在的未被删除的数据集的

> 所以数据结构需要是有序的），只需要先入先出（不需要从中间删元素）

zset 就是按 score 排序的, 你只要自己处理每次先删除第一个就行了

> 为什么两个加起来一个 issue 都没有？

@stabc
不是一个 issue 都没有, 而是一个 Open 状态的都没有. 兄弟你查 Closed 状态的, 到目前 arpc 有 47 个, nbio 有 242 个.
一个 Open 状态的都没有有两个原因:
1. 作者个人形单影只, 宣传力度不够, 吹个牛说, 虽然功能性能个方面都算是同领域 Top 级的, 但知名度太低, 知道的人少, 来 issue 的人也就少. 看看其他一些同领域的, 功能比这个少, 性能不比这个强, 但是 star 比这多的多, issue 不解决比这多的多
2. 每次有 issue, 作者都尽量迅速答复和解决, 所以除了极个别迷案无果而终, 绝大多数都已经解决了然后就关闭了

@prosgtsr 这算是我职业生涯里的最佳命名了

@spritecn 末期末期, 还没全退, 但是准备中...

@kingcanfish "激情探讨", 做清醒的自己~

@huig 来来来, 兄弟一起干 BA

@gongquanlin #2 感谢支持! 欢迎多来交流!

这个同事问题很大, 但是 OP 自己作为管理者也有问题, 基本没看到培训流程和方法, 只是东西丢过去让别人自由发挥.

例如生产环境, 权限不是随便就能给的, 至少要带一段时间非生产环境熟悉了之后才可以, 并且刚上手生产最好是每个操作也一块看下, 确实手稳再给他自由发挥的空间, 否则就容易挖坑. 我自己部门的新人, 至少要培养观察两三个月才会给生产, 观察期间如果觉得这人性格和做事方式不稳, 那尽量不给, 甚至直接就试用期过不来辞退了.

OP 可以如何改进？
先根据自己这块的实际情况, 梳理下工作内容工作流程和新人的培训流程, 比如新人培养至少多少时间, 需要熟悉哪些环境和业务和操作流程, 需要进行答辩, 需要非生产环境安排任务操作看看性格和做事风格是否会带来乱子, 基本每周都一个章节每个章节一个考核这种.
非生产环境都 ok 了再给生产环境, 谨慎带一段时间.

OP 可以如何自保？
做到上面改进的部分, 物竞天择适者生存, 能通过考核的人问题不大, 不需要你担忧自保.
如果改进的培训部分他做不到, 可以根据培训过程中对他的能力给出你的合理评估, 如实报告给你的领导, 即使是说他的不好也尽量委婉而且对事不对人不要牵扯人品, 说话也要自己谦虚并且委婉些面的打老板和领导的脸让他们以为他们自己不靠谱, 而且把决定权丢给老板和领导, 比如委婉建议是否安排他转个部门之类的(甚至辞退).


合理的方法和流程, 自己做的都是阳光下的, 再把话术整理好, 决定权和面子给老板和领导留着, 其他的不需要太在意, 除非是老板和领导故意想整你否则不太需要考虑自保的问题, 如果是老板和领导要整你, 自保也保不了, 而且从 OP 内容看至少现在不涉及整人的事情

拆一拆说不定还能做点器官移植或者有偿器官捐献......

3000 多的东西, 他才赚了你 2000 多

单方面经济关系的人, 通常都不是真正的朋友关系, 你打游戏开黑不会找他, 你去桑拿洗脚泡妞不会找他. 这种是经济上的熟人罢了

真正的铁子朋友就是常见那几句:
一起同过窗
一起扛过枪
一起嫖过娼
一起分过脏
...

双人运动的时候对方情绪稳定
给她惊喜的时候对方情绪稳定
男人临终的时候对方情绪稳定
......

小伙子你这不叫延迟满足, 你这叫:

少年不知 X 珍贵, 老来没 X 空流泪

> 如果拿 js 来做对比的话，很明显 js 努力的方向一直是用同步的方式写异步逻辑，经过了 promise 到 async/await 的迭代，但 go 这边就很符合直觉。

对对, 非常同意. promise 对于很多人都是个坑, 因为看着是顺序的实际上不是本次 eventloop, 所以遇到 for 循环里的 promise 或者 promise 后面的逻辑, 其实都是违反时序直觉的, 很多新手遇到了 bug 都仍然难搞懂这个. async/await 虽然提供了, 但也是难于理解难于使用, 比 goroutine 自动档差远了

这么有毅力不容易, 加油 OP!

> Go 最重要的贡献之一是基于 chan 的思维模型：Share memory by communication 。
> 日常反复被强调的 goroutine 其实不重要，很多语言也可以有样学样。

chan 挺好, 但本质上相当于个阻塞队列, 即使没有 golang, pipe/cond_t+mutex/sem 之类的传统的进程间通信/线程同步的这些也都能实现类似的阻塞队列组件. 但多进程多线程和这些 syscall 要么阻塞线程要么异步.

Share memory by communication 更像是从 erlang/actor 拿来的, 但 golang 整个语言本身没有像 erlang 那样纯 actor.
actor 是个太监模型, actor 之父是为了他们自家电信业务造的 erlang, 电信的那种每个 erlang 进程处理一个连接, 设备进行管理功能也不算复杂不需要连接之间有复杂的交互, 这种场景用 erlang 的进程通信比较简单.
但纯 actor 并不适合于复杂的业务, 例如连接之间有复杂的交互.
而且不管哪种 actor, 让一些即使很简单的交互, 或者一些用普通的逻辑处理比较简单的交互, 也都强制必须用通信的方式, 都是需要数据拷贝/调度或者切栈上下文之类的, 这些都带来了额外的性能损失. 性能损失这一点, chan 也是类似的, 简单的有性能需要的功能, 用 chan 未必见得划算.

runtime 基础之上:
goroutine 让大家绝大多数时候能写同步代码, 这个解决了传统高并发高性能的 c/c++/java netty/nodejs 等语言的 callback 逻辑不直观和 callback hell 的问题.
传统的进程间通信/线程同步 syscall 封装组件, 即使实现同步组件, 但阻塞的是进程/线程, 所以不能用 goroutine 与这些 syscall 结合来让大家写同步代码, 所以需要 chan 这种基于 runtime 的轻量阻塞队列实现.

golang 标准库提供了个基于 runtime 的 cond_t 也可以自己封装下实现 chan 或者类似的组件, 但 chan 已经足够方便了, 我暂时想不到有需要自己搞这个的需要.
从这些角度讲, 我觉得 goroutine 仍然是最重要的; chan 很好, 但是次之, 因为也有很多场景是不需要甚至不适合用 chan 的.

我个人觉得 Java 开发效率是最低的.
—— 但这只是我个人对我个人用 Java 的感觉, 而不是我认为所有人用 Java 都如此.
—— 至于原因: 我个人不喜欢 Java 的臃肿, 所以一直抵触用 Java, 所以也没有学习过 Java 的那些框架.

很多说 Golang 开发效率低的人, 其实跟我类似, 首先他们嫌弃 Golang 提供的语法糖/特性太少, 其次他们也不熟悉 Golang 社区的成熟框架/解决方案. 而且这些人绝大多数都是做 CURD 对性能没太大需求, 所以带来的性能提升他们是睁眼瞎一样完全忽视.
他们从来没考虑过是不是因为他们自己都不够熟悉 Golang 的正确姿势和成熟方案, 而仅因为 Golang 没有其他语言的那些姿势和方案, 就来无脑喷 Golang 开发效率低.
这种类似的观点言论, 可以反映出他们自己的水平还不够高, 但我这里说他们水平不够高并不是贬义, 因为这些人很大一部分是经验年限比较少的, 多数人年轻时候都菜, 慢慢成长吧, 等自己真正脱离了 CURD 这个 Level 的时候, 真正懂得去思考系统和工程的时候才能给出客观评价.

设计模式的糟粕害人挺多的, 观察者是少数实用的之一, 和发布订阅本质上是类似的.
没必要把自己陷在某个语言的实现方式上, 理解它的用途, 融会贯通的实际运用就可以了. 我当年写 C 为了模块之间解耦自己就搞了个出来, 当时都不知道这玩意是个设计模式, 后来看设计模式的书才知道原来这叫做观察者.

BTW, 至今设计模式我也没记住几个, 反倒让自己代码通常比多数人更简洁一点.

@lesismal #59 https://www.moomoo.com/hans/news/post/36558404?level=1&data_ticket=1735026819434878