上面的说法跟 LZ 提的没看出有什么区别

单线程也很难就直接保证了，没有考虑 处理完成，但是更新状态失败这个问题。

要 Exactly Once 基本是要业务层保证，幂等，可 redo

提个观点，我是不会让一个使用很低频的 Electron 应用挂在后台的。。
更何况你这个更加了，竟然还要起 MySQL，Redis 。。

结构化

分布式锁最基本的是有一个续约机制，但是因为各种原因导致续约失败，导致锁超时，就有可能出现并发的情况。

所以，我是不建议使用分布式锁，一般都是用某种分区机制，转顺序化串行。

哈哈哈哈，见识到原来大家都这么的职业化，只通过 ISSUE，ticket 沟通。

我比较同意楼主的，不喜欢现场去找人，也没要求一定立马回，有时间就回感觉没问题的啊。

超时怎么处理

爱吃脆脆的青苹果

说的有道理的，很多做技术的人都不屑于去做这些，其实这些有些真的很赚钱的。

程序员大都在一线，很多人都习惯性的忽视了 18 线城市的消费习惯。

有兴趣可以看看 TomsInsight 的系列分析。

不过，有一说一，做这些都是有很高风险，拿稳定的工资更简单些，程序员的收入一般不错，也不想乱折腾了。

@qingwuguo 666，最近也在想着玩程序化交易，看了这个，感觉自己想的太简单了。得系统化学习才行。

@qingwuguo 大佬自己的应该还在跑吧，最近战绩如何。

主键还是要的。

早睡早起，然后就是吃药了。
这个跟是不是程序员没关系，一般都是遗传的。

@hantsy kotlin，确实是的，但是 kotlin 是没有绑定 JVM 的，升级降级会简单一些。

@zichen 我的关注点是 preview 的 feature，没有一个兼容的机制，preview 的后来被删了就尴尬了，我觉得大家是不敢用的。Go 也是 6 个月一个版本，但是会兼容的； Java 以前也是兼容著称的，现在改成这种发布，真没觉得好。

现在来说，8 确实已经够用了，后面的更新都是不痛不痒的，大家都不怎么关注。
估计下个大发布，就是 Loom 了。

@hantsy
@wysnylc 问题是 preview 的 feature 万一后面的版本改了，甚至删了。。你的代码怎么办，就被锁定版本了。或者出个转换工具，类似 js 的 babel。。现在还是 kotlin 稳，把 JVM 作为 runtime，语言特性不跟特定版本绑定。不用担心后续兼容性。

看起来不错，其实自己也是想写一个写作软件的，好几年了。。

感觉，作为一个后端，要做独立开发者，还是有点难度，UI 设计和实现都是个问题。。