今年年初有个项目需要用到Django，第一次接触REST（Representational State Transfer。表述性状态传递）风格的编程语言，也就是面向资源编程。面向过程、面向对象和面向资源都是抽象角度的不同，按周志明老师的说法，即：
这也是为啥面向过程的语言性能一般最高，而目前却大量使用面向对象，因为面向对象更容易理解，在大型项目中，大家协作起来更方便。再抽象一点面向对象其实是一个主客体的问题，你编写的系统其实是subject，而系统产生或者操作的对象都是object。
而其实在REST风格之前，还涌现了好多别的架构，CORBA、Web Service但都因为这样那样的原因而未流行起来（具体可以参考周志明老师的新书《凤凰架构》）。
而REST这种架构风格对HTTP原有的语义进行了阐述，在这种风格中，原有如在传统Java中，你要获得用户信息，可能需要建个接口getUserInfo；删除数据要写个接口命名为deleteUserById等等。但是，在REST这种风格中，你使用HTTP的GET方法，然后URL中使用User，它的语义即为查询user；当你需要删除用户id为1的用户，只需要使用HTTP的DELETE，然后URL使用/user/1/，它的语义便是删除id为1的用户。
1.对事务的支持。这几乎是最大的问题，下面Django也会谈到这个问题。
2.基本依赖于HTTP。UDP等无法支持。
3.批量处理问题。当我需要增加100条数据时，总不能使用调用100次PUT吧。
4.幂等性的问题。这个大多数REST风格框架实现中，基本都有一个实现，比如POST是更新的语义，不是幂等的，但是PUT这种增加，我误操作多按了一次，不能增加两条吧。
Django 是一个由 Python 编写的一个开放源代码的 Web 应用框架。而DRF（Django REST Framwork）是通过Django对REST风格的一种实现，很多一些网站如知乎、豆瓣和微信支付的一些业务都是Django。
Django已经很重了，DRF更重，经常调起错来很多层错误嵌套，调试起来特别麻烦。但是开发和上手起来是真快。比如当我使用DRF生成一个app后，我只需要下面两行代码就可以使用HTTP的语义设备表进行增删改正了。
class Device_numVice(viewsets.ModelViewSet):
# queryset要传queryset对象，查询了所有的图书
# serializer_class使用哪个序列化类来序列化这堆数据
queryset = Device_num.objects.all()
serializer_class = Device_numSerializer上面代码中需要有个Device_num的类，相当于Java里的POJO
class Device_num(models.Model):
did = models.IntegerField('设备id',)
num = models.IntegerField('设备值', default=0)
update_time = models.DateTimeField('更新时间', auto_now_add=True)
class Meta:
verbose_name = "设备值"
db_table = "device_num"
def __str__(self):
return self.num然后有个序列化，默认的就行：
class Device_numSerializer(serializers.ModelSerializer):
class Meta:
model = Device_num
fields = "__all__"
其余都是系统内置类，这种方式上手简直太快了，当然毕竟是Python实现，而且框架重，性能较一般。
这个问题之前学习的时候每太重视，教研室项目这事务方面的要求很少，但之前有一次实验室的数据库勒索病毒问题，现在对MySQL增加了binlog的备份，然后定期将这个备份使用git发布到Gitee的私有库上。当这一套设置完以后，发现服务器上所有用DRF开发的服务都不可用了。
'Cannot execute statement: impossible to write to binary log since
BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine
limited to row-based logging. InnoDB is limited to row-logging when
transaction isolation level is READ COMMITTED or READ UNCOMMITTED.')翻译过来大概是
'无法执行语句：无法写入二进制日志，因为BINLOG_FORMAT=STATEMENT，并且至少有一个表使用的存储引擎仅限于基于ROW的日志记录。当事务隔离级别为“读已提交”或“读未提交”时，InnoDB仅限于ROW日志记录。
然后一般MySQL的隔离级别是可重复读，这里说因为数据库设置是读已提交或读未提交，无法使用binlog的STATEMENT模式。但我查询数据库的隔离级别确实还是可重复读。
select @@transaction_isolation;再往下查，发现Django默认的事务隔离级别是读已提交。此时解决方案为两种：1是将Djang连接时也默认设置为可重复读。2.将binlog设置为row或格式。
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> flush privileges;注：因为binlog已经是STATEMENT了，设置为MIX可能会失败。MIX的意思是由MySQL决定何时使用ROW，何时使用STATEMENT。
为什么呢？为什么在读未提交和读已提交下他的binlog不能设置为STATEMENT？
其实很简单，binlog是数据库服务层级别的日志，除了备份外还要用来做主从数据库的备份，而他的提交机制只是简单的时间前后行为，当事务提交时它也生成，而对事务的隔离性支持用到的undolog是在InnoDB存储引擎下才是生效，对数据隔离性的支持也是靠这个日志，而这个日志并不会进行主从同步。从库的undolog生成是按binlog回放时的时间进行生成的，而主库binlog的的生成时按事务提交前后进行持久化的，此时出现主从undolog日志原意义不一致的情况。
注：对undolog的同步是很难实现的，总不能undolog没更新一下就同步，这样对性能影响太大了，而且undolog是InnoDB特有的，总不能再开发一套undolog的同步机制。
即使在读已提交的级别下，你对某表的操作，在主库中因为有redolog和undolog保证，会有对应隔离性支持，但它同步到从库这个隔离性就无法支持了，会导致主从数据不一致。如：
user（id,scoe）
1,10
2,22
3,33
//其中id自增在事务1（先于事务2开始）：
INSERT INTO user(score) VALUES(44);事务提交；
在事务2中（后于事务1开始）：
INSERT INTO user(score) VALUES(55);
//事务2提交。事务2的binlog也会提交
//此时事务1提交,binlog也会提交此时主库应该是：
user（id,scoe）
1,33
2,10
3,10
4,44
5,55而从库执行顺序却是事务1执行完后，再执行事务2，数据成了
user（id,scoe）
1,33
2,10
3,10
4,55
5,44而ROW格式的日志记录的不是语句，而是这一行数据变化前和后的真实数据。当然从存储空间上讲，ROW比STATEMENT大了最少一倍。（这也是为啥有MIX格式的原因）。
在不可重复读的模式下，因为GAP锁的存在，事务2是不允许插入，需要等待事务1提交才行。
但是，哪怕是在可重复读情况下还是不建议使用Statement模式，仍然容易出问题，如中有 limit，所以这个命令可能是 unsafe 的，因为主从走的索引不一定一样。
而按林晓斌老师的说法，现在大多数互联网公司会使用ROW格式的MySQL，因为即便是MIX，他里面也会有STATEMENT，恢复日志的时候很难自己定制。且STATEMENT会强行依赖上下文，可能带来数据的不一致问题。
参考文献：
1.林晓斌，《MySQL实战45讲》，极客时间。
2.周志明，，GitHub的开源文档。