springboot

Spring Boot做了那些没有它你也会去做的Spring Bean配置

“习惯优于配置”的理念让项目快速运行起来

容易创建一个独立运行(bootable jar,内嵌Servlet容器)、准生产级别的基于Spring框架的项目,使用Spring Boot你可以不用或者只需要很少的Spring配置

clion wsl

clion 开始支持wsl环境了,win 10 可以方便的直接编译linux的pthread,socket等相关内容,可以在直接愉快的浏览相关源码了

持续重构

什么是重构??

不改变软件可观察行为的前提下改善其内部结构 —Martin Fowler

通俗说法:看起来没做啥调整,让系统继续更好的满足客户需求。同时,希望重构完成后,这个系统能够多蹦跶几年

mysql gtid

5.6引入GTID,全局事务标示符

每次事务提交都在binlog生成1个唯一的标示符,由server UUID(第一次启动MySQL自动生成,auto.cnf)和事务ID组成

首次提交的事务ID为1,第二次为2,以此例推

Xtrabackup

小库可每天完整备份,也用不了多少时间

大数据量备份与还原,始终是个难点。MYSQL超10G,mysqldump导出就比较慢了

MySQL自带工具并不支持真正的增量备份,二进制日志恢复是基于时间点的恢复而不是增量备份

xtrabackup,Percona CTO Vadim参与开发基于InnoDB的在线热备工具,开源,免费,备份恢复速度快(mysqldump 为单线程),占用磁盘空间小,不同情况下的多种备份形式

支持 MySQL、MariaDB 和 Percona

可提供的流备份,可以直接保存到远程机器上(本机硬盘空间不足时很有用)

或是搭建主从,用流式备份大大简化备份后的压缩复制的开销

背书,Facebook 早期用它进行增量备份

XtraBackup 是物理备份,速度很快,能自动验证备份是否有效,自带增量和差异备份功能,在上面功能实现的同时还是热备,对很多公司应用场景来说,已经算是强大到无以复加了

xtrabackup包含两个主要的工具,xtrabackup和innobackupex

  1. xtrabackup只能备份innodb和xtradb引擎的表,不能备份myisam引擎的表

  2. innobackupex前身是封装了xtrabackup的Perl脚本,后重写成可执行文件,支持同时备份innodb和myisam,对myisam备份时需要加一个全局的读锁。myisam不支持增量备份

xtrabackup中不备份表结构,innobackupex调用xtrabackup子线程后再备份表结构,故常用innobackupex,xtraback不做日常使用

db

数据库的东西,往往一个参数就牵涉N多知识点

gorouting

CSP是 用于描述两个独立的并发实体,通过共享的通讯 channel进行通信的并发模型

CSP中channel是第一类对象,它不关注发送消息的实体,而关注与发送消息时使用的channel

这是一套独立于语言的东西

grpc

关注 grpc 很久了,终于今天看见nginx 即将原生支持grpc后,在go里,跑起了第一个 hello world

redis 脑裂等极端情况分析

哨兵(sentinel)模式下的脑裂 1个master与3个slave组成的哨兵模式(哨兵独立部署于其它机器) 刚开始时,2个应用服务器serv

rsa

.Net、Java 的RSA类库存在很多细节区别,尤其是它们支持的密钥格式不同

容易出现“我加密的数据对方不能解密,对方加密的数据我不能解密,但是自身是可以正常加密解密”等情况

证书相关

密码学相关的标准、协议很多,原理往往需要一些数学基础

想要程序马上work起来可能容易,想要搞清楚原理,需要花些时间才行

SSL,X.509,PEM,DER,CRT,CER,KEY,CSR,P12等

刚接触证书加密相关概念会感觉挺棘手,一下子来了一大堆新名词,看起来像是另一个领域的东西,而不是我们所熟悉的编程领域的那些东西,且很长时间都没怎么搞懂

pthread

传统UNIX中,进程(Intel所谓的task)是调度的最小单位

线程是在进程的基础上进一步的抽象,一个进程分为:线程集合和资源集合

进程中所有线程共享进程的资源,线程有私有对象:比如程序计数器、堆栈和寄存器上下文

复杂的软件往往需要有多个进程,fork+exev是很常用的技巧

网络服务的复杂性增长,fork开销成为瓶颈。产生vfork和copy-on-write技术,减小fork的开销

pthreads也是为了解决fork开销问题,同时能够支持SMP,进程内的多个线程可以分布在各个处理器上并行运行


2.6以前的调度实体都是进程,内核并没有真正支持线程

通过系统调用clone()实现,创建了一份调用进程的拷贝,跟fork()不同的是,这份进程拷贝完全共享了调用进程的地址空间

LinuxThread就是通过这个系统调用提供线程在内核级支持的(许多以前的线程实现都完全是在用户态,内核根本不知道线程的存在)

这种方法有相当多的地方没有遵循POSIX标准,特别是在信号处理,调度,进程间通信原语等方面

为改进,LinuxThread须得到内核支持,并重写线程库

两个竞争项目:IBM的NGTP(Next Generation POSIX Threads),Redhat的NPTL

IBM放弃了NGTP,Redhat发布最初的NPTL(redhat linux 9)。现NPTL成GNU C库的一部分

NPTL跟LinuxThread办法相同,内核里线程仍被当作是一个进程,且仍用clone()系统调用(在NPTL库里调用)

但是,NPTL需要内核级的特殊支持来实现,比如需要挂起然后再唤醒线程的线程同步原语futex

NPTL是1*1的线程库,就是当pthread_create()调用创建一个线程后,内核里就相应创建一个调度实体,在linux里就是一个新进程,这个方法最大可能的简化了线程的实现

除NPTL的1*1模型外还有一个m*n模型,通常这种模型的用户线程数会比内核的调度实体多

在这种实现里,线程库本身必须去处理可能存在的调度,这样在线程库内部的上下文切换通常都会相当的快,因为它避免了系统调用转到内核态

然而这种模型增加了线程实现的复杂性,并可能出现诸如优先级反转的问题,此外,用户态的调度如何跟内核态的调度进行协调也是很难让人满意

存储

以前公司seafile后端存储,根据官方支持,用了ceph

记一些相关的杂文

lisp

收一些关于lisp的杂文

Lisp的本质》是一篇雄文 作者是美国的俄罗斯移民,一位常年从事IT的程序员,写了这么一篇“洗脑文”,一篇类似传播宗教福音的宣教文

作者叙述了自己被Lisp洗脑的过程,从开始对Lisp的不解、甚至有些鄙视,到如何听到Lisp“先知”的教瑜,出于对大神的崇敬和膜拜,强迫自己开始洗脑的征程

突然有一天,作者“顿悟了”,羽化成仙了,在升天前的最后一刻,向尚未开化的芸芸众生们留下了这篇雄文

作者的“悟”来自于对先前的编程经验与Lisp之间的神秘联系

第一个出场的就是XML语言

21世纪初各大商业IT公司、大学和研究机构看好的,用来描述数据格式的语言

随Web Services的兴起,开始取代相类似的各种专用协议,成为网络传输数据和方法的标准格式

后成为各种编程语言的附属物:各种环境参数配置文件,甚至像迅雷bolt界面引擎这种

XML使用范围的扩大,逐渐发展出一套完整的XML技术,对XML文档的格式的专用语言、对XML文档数据的查询语言等等

XML最大优点,可以定制文档操作符的语义。付出的代价就是语言的笨重,句法多于语义

既可作标准的数据文件也可对某些操作定义其接口或者叫”签名”(signature),这样,XML实际上兼有数据和处理两方面的特征

而这,正是Lisp语言最本质的特征——自定义语言的语义。我不想掩饰当我看到这一段时的拍案叫绝心情

实时 os

非科班码农太多,实时非实时 OS都没听过

非实时os:Linux//Windows/mac OSX

实时os:uCOS/VxWorks/RTLinux

到底啥区别?哪个好?

C/C++并发编程—— 并发/并行、多线程内存模型

C++最基础的线程与锁模型资料丰富、简单易学

该模型导致的死锁、饥饿等等问题也是大家很头痛的事情

对于C/C++并发模型,还有很多其它的选择,比如Actor、CSP、协程等

并发编程的基础知识,并发与并行的区别和C/C++多线程内存模型

CAS

有这种情况,看了很多文章,知道 基于硬件的 CAS命令,set值一定成功,但到底为什么成功,或者说还是不理解CAS语义和基于语义后,算法该是怎样的

CAS的语义 我认为V的值应该为A,如果是,那么将V的值更新为B,否则不修改并告诉V的值实际为多少

java GUI

J2SE,J2ME,J2EE 的2 指Java1.2以后的版本,因为这个版本有个质的飞越,其中包括双亲委派模型

java singleton

java 中关于singleton 的坑比较深,看过几篇double check的文章,但还是一知半解是很正常的

整合几篇文章,记一下