那些年我们追过的网络库
发布于
framework

计算机史前文明时代,y2k problem 后,世界难题 “c10k problem”

八仙过海, 各显神通

NPTL 还没有研究出来. 还不能创建成千上万个线程 windows 还在蓝屏中挣扎, 无暇顾及网络

UNIX提供了 select() 系统调用,只支持 1024 个fd, windows 只64个

这种背景下, IBM 带领着MS先搞了 IOCP

开源人有开源的做法, 在 NIH 综合症的影响下, BSD 的人敢为天下所不齿, 发明了 Kqueue, Linux 捣鼓出了 epoll

分裂, 让人头疼

都声称自己的新接口对 select 有质的提升, 是破解 c10k 问题的不二法宝,你用也得用, 不用也得用

为了让自己编写的网络程序能跨平台, 程序员开始了对3大各自为阵的法宝的膜拜学习

除了需要应对多套互不兼容的 API , 异步本身也需要更高级的抽象, 把程序员从编写异步代码的地狱模式里拯救出来

程序员们急需一个上天入地无所不能的法宝的法宝, 把这3家法宝给统御起来

率先站出来的是 ACE

mysql 5.7 sys schema
发布于
mysql

介绍

5.7.7 引入 sys 系统库,专注于MySQL易用性,分析问题和定位问题,将更多的依赖sys schema,减少外部工具的使用

For Linux users I like to compare performance_schema to /proc, and SYS to vmstat.

performance schema和information schema中提供了信息源,但是,没有很好的将这些信息组织成有用的信息,从而没有很好的发挥它们的作用

MySQL 5.7对buffer pool的改进
发布于
mysql

重要组件buffer pool,缓存磁盘数据页,降低事务 io 代价,提高事务的执行速度,显著影响db整体性能,MySQL的每个版本都对buffer pool进行了一些改进

5.7 改进三方面

  1. buffer pool的dump和load
  2. 在线修改buffer pool
  3. 优化buffer pool刷盘
Reactor Proactor
发布于
io

I/O 编程模型

用户应用程序运行在用户态,只能访问有限的内存,不能访问外围I/O设备,如硬盘、网卡等; os运行在内核态,可以访问所有内存区域以及所有外围I/O设备

用户态应用程序访问I/O需要发起系统调用,由内核线程(指令)来完成

内核线程完成相应I/O操作(读取/写入),数据需要从内核态复制到用户空间的内存,应用程序从内存获取数据,才能继续完成相应业务逻辑的执行

  1. 用户空间通过系统调用通知内核准备数据 -> 等待数据
  2. 从内核空间复制数据到用户空间 -> 拷贝数据

由于拷贝数据实在内存中进行(或者内核内存空间映射到用户空间就更快了),因此速度较快,而等待数据则是两个阶段中最消耗时间的

《Unix网络编程》 IO模型:阻塞IO、非阻塞IO、IO复用、信号驱动IO和异步IO

五种可单独用其中一种,也可组合使用

POSIX 只分两类:同步IO和异步IO

一个IO操作分成 发起IO请求和实际的IO操作两个步骤

阻塞和非阻塞IO区别在于第一步发起IO请求是否会被阻塞

同步和异步IO区别在于第二个步骤是否阻塞请求进程

非阻塞是os做完IO操作再将结果返回前四是同步模型,最后一种是异步模型

  • 同步:指用户线程发起了I/O请求后,需一直等待或轮询内核I/O操作完成后,才会继续执行
  • 异步:指用户线程发起I/O请求后依然继续执行,当内核完成I/O操作后会通知用户线程,或者回调用户线程已注册的回调函数
  • 阻塞:指只有内核的I/O操作彻底完成后,才会返回用户空间
  • 非阻塞:指I/O操作被调用后,立即返回一个状态值,无需等到I/O操作彻底完成
golang flag and config
发布于
go

flag欠缺的

与命令行Parser的事实标准:Posix getopt(C/C++/Perl/Shell脚本都可用)相比,还有较大差距

  1. 无法区分 long option 和 short option,如:-h 和 –help
  2. 不支持short options合并,如:ls -l -h <=> ls -hl
  3. 位置不能任意放置,如无法放在 non-flag parameter 后面
MySQL 事务
发布于
mysql

事务广泛应用于订单系统、银行系统等多种场景

A给B转账500,需要做以下几件事:

  1. 检查 A 的账户余额 > 500
  2. A 扣 500
  3. B 加 500

正常流程走下来,A扣500,B 加 500,皆大欢喜

如果 A 扣了后,系统出故障了,A 损失 500,而 B 也没有收到本该属于他的 500

以上的案例中,隐藏着一个前提条件:A 扣钱和 B 加钱,要么同时成功,要么同时失败

事务的需求就在于此

spring transaction
发布于
java spring

三个组成部分:DataSource、TransactionManager和代理机制

无论哪种配置方式,一般变化的只是代理机制这部分

DataSource、TransactionManager 只根据数据访问方式有所变化

Hibernate DataSource 实现为 SessionFactory

TransactionManager 实现为 HibernateTransactionManager