ScheduleMaster上一次比较大的更新还是在6月份，转眼已经快过去4个月了，这段时间比较忙，中间只更新过一次修复了几个小bug。要总结这次更新的话，必须要用“千呼万唤始出来”了，因为这次不仅经历的时间比较久，还带来了大家期待已久的功能-多数据库支持，再就是对.NET Framework的支持。
不熟悉的朋友可以先参考以往的介绍文章：
先看一下本次的更新点。
V2.2更新日志
- 新增了对SQLServer和PostgreSQL的支持（来自@xueandfeng的PR，非常感谢！）
- 新增了对.NET Standard 2.0的支持
- Worker节点支持配置最大并发数
- HTTP任务支持自定义超时时间
- 修复了已知的bug
新功能可以做什么
项目最初使用的Mysql作为数据持久化方式，从发布开发，就有小伙伴一直问能不能支持其他数据库，因为对.NET平台的开发者来说使用SQLServer还是更多一些。但是那时候更多的考虑到整个项目部署的便捷性和跨平台（docker一条龙服务），而且刚好那段时间沉迷于Mysql，所以毫不犹豫的选择了它。虽然使用EntityFramework这样的ORM作为数据访问框架，但当时迫切的想完成核心功能快速发版，就没有考虑支持多种类型数据库，一直拖到现在。
在这过程中，支持多数据库的需求实在太大，有很多小伙伴自己拉源码改改就用上了，也有热心的小伙伴改完提了PR，不过我由于个人问题还是拖了一段时间到现在才处理。所以，经常用SQLServer或者更喜欢PostgreSQL的朋友有福了，再次感谢@xueandfeng。
另外，项目正式支持.NET Standard 2.0，这意味着项目不仅仅能支持.NET Core程序，同时也能支持.NET Framework（4.6.1及以上）程序了，一张图看个明明白白：
以上之外，worker节点可以支持配置最大并发数量了，这是Quartz.Net线程池的一个特性。之前收到锄头哥多次反馈大任务量同时执行时会有丢失的问题#38,多方排查后定位到线程池上。从Quartz.Net 3.0开始，默认线程池(Quartz.Simpl.DefaultThreadPool)开始使用CLR的线程池，但是仍然保留了maxConcurrency这个参数，它的默认值是10。在官网文档可以看到，在大任务量执行频率比较高时，建议调高最大并发量的值：
不过要注意的是，这个值并不严格意味着你最大能执行XX个任务，这取决于你的任务执行情况和系统环境。当你有大量高频率任务时，调高这个参数能明显改善任务丢失情况，ScheduleMaster给它的默认值是20。
我在忙什么
6月底我从广州裸辞，回到武汉开始找工作。作为今年疫情的最中心，武汉受到的影响还是非常大的，很多朋友劝我不要在这个时候换工作，但是由于一些原因我还是坚决地回来了。所以，还是逃不过现实的残酷，工作这么多年来第一次感受到找个靠谱的工作如此困难，当然这也和武汉的.NET大环境有关，前前后后花了好几个月才阴差阳错地来到现在这家公司。
目前从事云计算行业，有太多太多的专业知识要学习，而且还有好几门考证要求，实在应接不暇，初期曾一度想放弃。现在工作中主要的开发语言也转型到了Golang，什么前端后端运维数据库DevOps哪里需要往哪里搬，不断刷新自己的知识盲区。不过.NET还是会继续关注，这个项目还是会继续做下去。
最后，佛系推广一下。
作者唯一开源地址
：
https://gitee.com/hey-hoho/ScheduleMasterCore （只从github同步）
文档（还在逐步更新中）：
感谢大家支持~