本篇博客会深入分析条件变量实现来理解两个问题：

• 为什么条件变量要配合锁来使用 — 信号丢失问题
• 为什么条件变量需要用while循环来判断条件，而不是if — 虚假唤醒(spurious wakeup)问题

这两个问题不仅是C会遇到，所有语言的封装几乎都不可避免

先区分一下条件和条件变量，条件是指常用情况下，signal线程修改的值，使得cond_wait判断该值后不再阻塞

一直以来用的友言第三方评论系统倒闭了，现在连官方网站都打不开了。

所有的评论数据全部丢失，很伤。那我宁愿用开源的评论系统了，例如isso。

下面记录一下isso的使用方法(isso-0.11.1版本)。

安装(阿里云ECS的centos7.3环境)

1
2
3
4
5
6
7
8
9
10

安装pip,sqlite
yum install python-devel sqlite
升级pip
pip install --upgrade pip
根据报错提示安装依赖库
yum install libffi-devel
安装isso
pip install isso
新建立一个数据库目录
mkdir -p /var/lib/isso

做分布式事务的时候用到了存储过程加事务，由于忘记在存储过程中捕获异常rollback，导致了死锁

不过我select ... for update锁的是A表，实际线上却是B表被锁死

sql一块之前理解不深入，debug的过程重新复习一下

bug重现

简化逻辑重现核心bug

23个设计模式中，大部分多写代码都是可以直接领悟到的。

但是访问者模式不是。一个原因是这个模式的实际应用场景在后端开发流程中特别难遇到（一般用于解决固定问题，游戏开发的复杂逻辑应该能经常遇到），

另外一个原因是这个模式的实现有点绕。

这一篇并不包含实践环节，因为我并没有实际遇到这样的需求，因此本篇只能记录下学习过程了。

双重多态模式

习惯了golang的net/http/pprof的便利，c++的性能分析就显得繁琐了一点。

不过大致上还是一致的。

安装

包管理安装

1
2
3
4
5

centos:
yum install google-perftools google-perftools-devel

ubuntu:
apt-get install google-perftools google-perftools-devel

两个因素想做开源项目：

1 主导开发中间件系统的心愿已经达成，虽然中间磕磕碰碰的踩了很多坑。

但毕竟最终结果是好的。

唯一的遗憾就是没有开源了。

2 之前做了一些小网站，也累积了不少用户，但是对技术的磨练还是太少了。

特别是用户的增长出现瓶颈以后，架构和细节已经没有必要在优化了。这就让人产生了惰性。

认真做一个开源项目，会有bug issue和功能的issue。会有人去推动你不断探究。

我认为这会收获巨大。

具体项目没想好，可能是基础库（偏网络高并发？又一个轮子？），也可能是比较擅长的存储系统。

过载保护初探

距离上一篇过载保护的文章已经快一年了

上一篇文章是上一个项目分布式文件系统使用的，这个项目因为一些架构上的缺陷，并没有让最大的云盘服务接入。

没有那么大的量级，因此思考的过载保护方案也没有全部去实现。

新的项目有比较大的量级，在实现新项目的过载保护机制时会更全面。

我对23种设计模式的理解：

类模式和对象模式

有些博文会把对象分为类模式和对象模式，在我看来这两种模式是可以相互转化的。类模式主要强调类的继承决定结构或者行为，是通过继承的延迟到子类去实现，来完成模式。而对象模式则主要强调对象的关联来完成模式（关联一个接口用桥接模式完成继承，关联一个对象用适配器模式完成调用）。所以所有的类模式都可以转化为对象模式，而对象模式则不一定可以转化为类模式。

对写golang的同学来说这一点很容易理解，因为golang只有关联没有继承。想要通过继承来延迟到子类去实现，实际上子类是通过关联一个实现了某个接口的对象以及父类，然后把关联的过程封装在创建过程中。这样不同的子类通过动态的组合不同的对象来完成继承。（实际就是桥接模式）

创建型（5种）

我认为，控制反转和模版模式以及框架的概念是类似的，而控制正转类同于策略模式，库。

反转的是依赖关系，对框架代码来说，实现的就是模版模式。使用框架的代码，其实被反转调用了。而库则是主动去调用的，是一种策略模式。

因为控制反转是一种设计模式，因此所有语言都存在。

例如C，JS是以回调函数实现。而Python作为一种动态语言，这方面的支持更为强大。

对于OOP的静态语言(Cpp,Java,Golang等等)来说，通过继承的实现更为自然(Golang通过桥接模式变相实现)。

概括

最近在做的项目设计到一些金钱交易方面的事情。涉及到一些分布式事务的逻辑。

参考了一些资料，做一些总结。

• 一句话概括分布式事务：

一部分资源的数据更新以后，怎么保证另外一部分资源的数据也必须更新成功。