要说存储存在哪里问题都不大，大不了我 Redis 每次操作 sync 一次。
但是有些功能，比如事务，大量数据的索引，权限设计等等，确实不好弄

一般都用 Optional 处理可能非空值，因为一般不止一层，都是 a.b.c.d 。这么做省的哪里忘了判断 npe 了。

大哥你这用异步跑，又没有同步措施，协程没跑完，主进程就退出了，肯定有问题啊

@linvon 读的是 Redis 队列的数据，一次读 2000 条放入内存里，之后处理。也不是完全负优化，因为我开了 2000 个 goroutine 确实比顺序执行跑的快得多。但调优的时候发现 2000 条 ~ 3000 条的时候，速度就不提升了，这时候可能是负优化了。

@maemual 所以说还是有个度，超过这个度 goroutine 是低效的。

拼写错误实在是难以解释；
大小写是看整体风格的，如果 mysql 用小写，那么 redis 用小写也很一致，倒也无妨；
求职本是一件严肃的事情，拼写错误好比作文写了错别字，不会给你 0 分，但也会降低很多印象分。

实测，很方便，旅行带一个，手机、Mac 两不误

@azcvcza 所以 Java 是有语言缺陷的，有些语言就没有一些设计模式，设计模式是针对缺陷使用的

所以我想的是，能不用就不要用太多设计模式，没意义

多打击打击就习惯了，我也是这样

就一天，就这？心态放平。常规操作。

我写过一段时间的 NodeJS 后端，简单的前端页面（没用任何框架）。
JS 还算好学，就是太自由不好，而且没有什么工程化的东西；后来我写到 ES6，语法还好，但是和后端的语法不是很一致；到最后我写到 TS，发现包管理确实比较麻烦。最麻烦的是，由于语法过新，语言各种各样，各种需要转义的工具，增加了极多的门槛。
后来写过一点点 CSS，CSS 拆开来讲不是很难，组合起来就比较麻烦；需要记忆的点太多，如果搜索也很难去下手，需要经验（就比如我一开始不知道圆角，后来才知道这个专业名词，我开始搜索的是如何让表格变平滑）。这种东西我觉得属于另一种领域，后端一般涉及的是数据处理。
总的而言，前端这么难倒不是很难，是一个很相当需要一些经验的领域。

春节加班不

长期看好，老龄化、疫情，做基金不能看短期，楼主最好不要再投入基金了，先去学习下。
不会，不如不做。

不是很明白 泛型和简洁有什么关系 有了泛型 就不简洁了吗
没了泛型 排序代码要写多少种

package 级别的变量就是单例

我们用的配置中心是 apollo 。实地调研的结果是，consul 和 etcd 作为配置中心没有图形化的界面、权限管理、环境管理等，需要自己开发，最后选择了 apollo 。

@excxapp 微信这个场景相对容易些，失败之后再次设置 timer 即可，否则就是成功了，这个思路我是参考 JS 时间驱动的模型（楼上有位仁兄说得好，事件驱动模型，有的时候 JS 真是让人又爱又恨）。巧了，我任务的持久化确实是用 Redis list 做的，BLPOPRPUSH 维护两个队列确保任务执行完成。

我实践过，其实你这是两套东西，一个是任务存储，另一个是任务执行。这里只讨论任务执行。
原生 timer + context，很容易实现你这一套。
1 、timer 延迟
2 、性能自己控制，benchmark 可测
3 、传入 context，不需要 cancel 掉，启动时候检测 context
4 、建议不要更改执行时间，而是删除之前的任务进行重建，更改这种操作实现太复杂
5 、多个 timer 同时跑

这个是我在目前公司实现的，没有任何问题，简单方便。不建议框架，没必要。