python3-multiextends

2019-06-05

class P1(object):
def foo(self):
print(‘p1-foo’)

class P2(object):
def foo(self):
print(‘p2-foo’)

def bar(self):
    print('p2-bar')

class C1 (P1,P2):
pass

class C2 (P1,P2):
def bar(self):
print(‘C2-bar’)

def foo(self):
    print('C2-foo')

class D(C1,C2):
pass

>

d=D()
d.foo()
C2-foo

展开全文 >>

python-metaclass

2019-06-05

https://realpython.com/python-metaclasses/
https://docs.python.org/3/library/functions.html#type
https://www.cnblogs.com/tkqasn/p/6524879.html

➜  ~ python3
Python 3.7.3 (default, Mar 27 2019, 09:23:15)
[Clang 10.0.1 (clang-1001.0.46.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> Test = type('Test',(),{'bar':True})
>>> Test
<class '__main__.Test'>
>>> Test.bar
True
>>> def echo_bar(self):
...     print(self.bar)
...
>>> FooChild = type('FooChild',(Test,),{'echo_bar': echo_bar})
>>> aaa = FooChild()
>>> aaa.echo_bar()
True
>>> hasattr(FooChild, 'bar')
True
>>> hasattr(FooChild, 'echo_bar')
True
>>> FooChild.__class__
<class 'type'>
>>> FooChild.__class__.__class__
<class 'type'>
>>> bbb = FooChild()
>>> bbb.__class__
<class '__main__.FooChild'>
>>> bbb.__class__.__class__
<class 'type'>
>>>

>>>
>>> def my_meta_class(future_class_name, future_class_parents, future_class_attr):
...     attrs = ((name, value) for name, value in future_class_attr.items() if not name.startswith('__'))
...     uppercase_attr = dict((name.upper(), value) for name, value in attrs)
...     return type(future_class_name, future_class_parents, uppercase_attr)
...
>>>
>>> class FOO(object):
...     __metaclass__ = my_meta_class
...     bar = 'bar'
...
>>>
>>> dir(FOO)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__metaclass__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'bar']
>>>
>>>
>>> foo = FOO()
>>> dir(foo)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__metaclass__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'bar']
>>>
>>>

展开全文 >>

分布式事务和 CAP, BASE

2019-06-04

之前写过博文，聊过事务的特性（ACID）和隔离级别等等。但是在当代互联网中，尤其是后端微服务化之后，必须要解决事务跨服务的问题，也就是分布式事务。

CAP

在谈怎么完成分布式事务之前，首先要明确的是，完成事务的强一致性在一个分布式系统里是不是必须的。这里就引入了CAP理论，又叫布鲁尔理论。理论内容是，C（consistency）数据一致性, A（Availability）服务可用性（任何时候请求都可以被响应）, P（Partition tolerance）分区容错性（多分区之间（多节点间）通信可能会失败，这种情况发生时系统仍需能处理）这三个组成分布式系统的特性，任何时候都只能选择其中两个，放弃一个。

一般的分布式系统，A是必须的，P是必须的。来思考一下，当假设AP都满足的情况下，也就是分区间通信如果出现了问题，这时候用户访问服务，服务端仍然要返回给用户响应，那么中断通信的分区之间的数据传输就必须能延后处理。这时候就产生了实时的数据不一致性，C得不到满足。而放弃C也是大部分分布式系统的选择。

BASE

BA（Basic Available）S（Soft state）E（Eventual consistency）是现在分布式系统经常遵循的原则。系统只需要做到基本可用（繁忙时候可以选择服务降级），柔性状态（数据短期在各分区之间不完全一致），遵循最终一致性，就可以了。

分布式事务 —— 2 phase commit 两阶段提交

当需要保持事务的ACID特性时，就需要有办法在分布式系统里实现事务特性。其中一种协议是2pc（两阶段提交）。

两阶段提交协议需要基于以下假设：

有一个节点被选为协调者（Coordinator），其他节点为参与者（Cohorts）
所有节点的日志都能持久化
所有节点损坏后都可恢复

分布式事务 —— 3 phase commit 三阶段提交

两阶段提交存在很多问题，比如在commit过程中有节点commit后挂掉了，且通知给了唯一的协调者协调者也挂掉了。这个时候新选出来的协调者则完全无法确定之前的节点是否提交了事务。三阶段提交是对两阶段提交的改进，可以理解成在两阶段提交的前后阶段中，多增加了一个预提交阶段。

参考文献：
https://blog.csdn.net/u010425776/article/details/79516298
http://www.ruanyifeng.com/blog/2018/07/cap.html
https://www.cnblogs.com/toov5/p/9998395.html

展开全文 >>

IO多路复用

2019-05-26

上周五和同事聊天，从python的协程实现聊到网络TCP连接，最后落到了IO多路复用。于是觉得需要深入看一下I/O非阻塞具体实现的原理。

https://www.cnblogs.com/welen/articles/5385837.html

展开全文 >>

JWT 详解

2019-04-11

展开全文 >>

MySQL数据库隔离级别

2019-04-08

ACID作为数据库（事务）特性大家熟知。今天想认真总结一下 I - isolation 隔离性。MySQL一共有以下四种隔离级别

Read Uncommitted

这是最弱的隔离级别——可以理解为没有任何隔离。情况发生在：

事务A在更新数据，比如 update count from 10 to 20
事务B在A刚刚更新的时候读入了数据，读入 count = 20
事务A在提交事务过程中出错，数据回滚，count is back to 10

这样就造成了脏读 dirty read

Read Committed

为了避免上述情况，可以让B只能读入已经commit过的数据。这样如果事务A还没有commit，它涉及到的数据变化B是看不到的。这种隔离方式有效避免了脏读。

然后又有情况发生了：

事务A需要多次读入同一数据。第一次读count=10
事务B更新 count from 10 to 20
事务A继续读，发现count变成20了。数据不能一致。

这就造成了不可重复读 non-repeatable read

Repeatable Read

为了避免上述情况，让A在commit之前，读入的数据（涉及到的行row）都是相同的数据快照(snapshot)（第一次select之后，创建快照，之后select都来自这个快照），这样就隔离了其他事务对涉及数据的任何操作。这个隔离级别已经相对较高了，也是MySQL默认使用的隔离级别。相对来说开销也会比较大，性能会降低。

然而还是有情况发生：

事务A在commit前读入的行数据本身再次read是一致的
事务B insert 了一条数据 count = 10
事务A批量更新了所选中的行数据（第一次读入的数据快照），set all counts to 20，commit后事务结束
事务A结束后，发现count不仅多了一行，还出现了10这个已经改掉的值

这就造成了幻读 phantom read

Serializable

终极办法，完全隔离各个事务之间的影响。基于 Repeatable Read 的基础之上，凡是涉及到的数据，在本事务commit之前，其他事务都不能对相关数据做操作，知道本事务结束。

这是最高隔离级别，开销也最大。

参考文献

https://mydbops.wordpress.com/2018/06/22/back-to-basics-isolation-levels-in-mysql/

展开全文 >>