2019-10-30感觉这一节超级棒，老师通过事务的例子来解释共享状态的调度很深刻。
我对老师的问题关于共享状态调度的核心解决并发冲突的思考：
一个job由多个task组成，一个job要么全都执行，要么全都不执行，就像老师说的理解成一个事务；
1.job执行执行的时候如果阻塞等待资源，我们可以将阻塞加上超时时间，超时后还不能获取到资源，当前job主动释放自己已经占有的资源，这可以叫做等待超时时间；
2.如果一个job占有了一些资源，正在执行，我们可以给当前job设置一个超时时间，如果job在超时时间内还没把资源执行完，自己主动释放占有的资源，回滚job的所有task，这可以理解成作业超时时间
3.多个job的多个task在抢资源的时候，我们可以设计一个公平和非公平的抢占队列
4.共享状态下的调度有一个特点是每个调度器都有全局的资源，这个可以这样改进一下：每个调度器的资源分为两部分组成，一部分独占，一部分由共享抢占获取，这样减少并发的程度；这让我想到了操作系统的内存模型，一个核心占用一部分固定内存，然后其它的内存是共享的，也就是可以抢占的展开 2
2019-10-21解决并发冲突的方法就是加锁，在分布式架构中可以采用分布式锁，具体有前面讲到的三种，基于数据库的，基于redis的，基于zookeeper的分布式锁。 1
2019-10-21关于并发其实数据系统中一直很早就在处理这种问题：从早期单机RMDB->读写分离->一主多从->内存库【虽然市面上各种分类众多，可是个人还是偏向这种说法，各种关系太复杂了】。
谈不上什么特别好的解决方案：就谈谈老师课程中提到的Google对此的做法吧MVCC，其实这确实是一条解决的方式和思路，就像内存库就无法做到ACID特性，只能牺牲部分。目前主流其实就是老师文中所说的先锁或者后验证。
前段时间和本地的同行交流发现其实随着现在系统的越来越复杂：操作系统都开始特性化的时代确实感觉定制化的东西已经越来越多的出现在计算机的各个方面，如何从中获得一个相对中立的方案才是关键吧。 1
2019-12-13看了这篇文章，感觉只要有了类似redis和锁后，这个世界已经不存在单点问题了。
2019-10-29不同的体系结构是否对选择不同的调试结构有影响？
2019-10-22很抽像，能不能描述一下调度器做了哪些事情，任务举几个例子，共享状态调度的资源状态和任务状态有哪些
2019-10-21能想到的解决冲突的方法就是加锁了，乐观锁或是悲观锁，本质上都是让并行变串行。当然也有一些可以优化的点，比如读读并行。
2019-10-211.同步
给资源编号，按照一定的顺序加锁，释放锁，以免出现死锁
2.CAS compare and swap
可能还有其他方式，可以参考维基百科的Synchronization条目