grpc c++使用以及踩坑
两个因素想做开源项目:
1 主导开发中间件系统的心愿已经达成,虽然中间磕磕碰碰的踩了很多坑。
但毕竟最终结果是好的。
唯一的遗憾就是没有开源了。
2 之前做了一些小网站,也累积了不少用户,但是对技术的磨练还是太少了。
特别是用户的增长出现瓶颈以后,架构和细节已经没有必要在优化了。这就让人产生了惰性。
认真做一个开源项目,会有bug issue和功能的issue。会有人去推动你不断探究。
我认为这会收获巨大。
具体项目没想好,可能是基础库(偏网络高并发?又一个轮子?),也可能是比较擅长的存储系统。
再看过载保护
设计模式思考
我对23种设计模式的理解:
类模式和对象模式
有些博文会把对象分为类模式和对象模式,在我看来这两种模式是可以相互转化的。类模式主要强调类的继承决定结构或者行为,是通过继承的延迟到子类去实现,来完成模式。而对象模式则主要强调对象的关联来完成模式(关联一个接口用桥接模式完成继承,关联一个对象用适配器模式完成调用)。所以所有的类模式都可以转化为对象模式,而对象模式则不一定可以转化为类模式。
对写golang的同学来说这一点很容易理解,因为golang只有关联没有继承。想要通过继承来延迟到子类去实现,实际上子类是通过关联一个实现了某个接口的对象以及父类,然后把关联的过程封装在创建过程中。这样不同的子类通过动态的组合不同的对象来完成继承。(实际就是桥接模式)
创建型(5种)
控制反转的思考
我认为,控制反转和模版模式以及框架的概念是类似的,而控制正转类同于策略模式,库。
反转的是依赖关系,对框架代码来说,实现的就是模版模式。使用框架的代码,其实被反转调用了。而库则是主动去调用的,是一种策略模式。
因为控制反转是一种设计模式,因此所有语言都存在。
例如C,JS是以回调函数实现。而Python作为一种动态语言,这方面的支持更为强大。
对于OOP的静态语言(Cpp,Java,Golang等等)来说,通过继承的实现更为自然(Golang通过桥接模式变相实现)。
初探分布式事务
ADX信息调研
golang字符处理
golang字符处理已经踩过好几个坑了,记录一下
emoji表情的处理
用的mysql版本比较老,不支持emoji,所以需要golang来去除emoji表情
判断思路是普通汉字utf8下都是3字节内,而emoji表情是4字节,如果大于4字节就过滤掉即可
1 | import "unicode/utf8" |
mysql隐式转换导致的越界bug
之前用触发器做数据统计
然后还是一不小心踩坑了
触发器新建了一张fileinfo表,file表中增删查改的信息都会以触发器的形式去修改fileinfo表
后来发现由于mysql是行级锁,由于file表的操作QPS会很高,这个行级锁会造成很大的性能损失
所以需要把增删查改写入随机行。