2013 年我接触 Python 的时候，就听闻 Python 的网络编程能力十分强大。因此，在熟悉 Python 的基本语法之后，我就和几个小伙伴一起合作，试着用 Python 的 urllib 和 urllib2 库构建了一个百度贴吧 Python 客户端。 然而，使用的过程中，我发现两个标准库的语法并不自然，甚至可以说十分反人类——用着很难受。又有，我平时使用 Python 甚少涉及到网络编程的内容。因此，Python 的网络编程就被我放下了，直到我认识了 requests 库。 初识 requests requests 库的宣言是 HTTP for Humans （给人用的 HTTP 库） 我们首先来验证一下。 在网络编程中，最最基本的任务包含： 发送请求 登录 获取数据 解析数据 反序列化打印内容 我们以 GitHub 为例，先看一下使用 urllib2 要怎么做。为了把事情弄简单点，我们假设实现已经知道，GET 请求 https://api.github.com/ 返回的内容是个 JSON 格式的数据（实际上通过 content-type 也能判断）。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 import urllib2 import json gh_url = 'https://api.github.com' cs_user = 'user' cs_psw = 'password' req = urllib2.Request(gh_url) password_manager = urllib2.HTTPPasswordMgrWithDefaultRealm() password_manager.add_password(None, gh_url, cs_user, cs_psw) auth_manager = urllib2.HTTPBasicAuthHandler(password_manager) opener = urllib2.build_opener(auth_manager) urllib2.install_opener(opener) handler = urllib2.urlopen(req) if handler.getcode() == requests.codes.ok: text = handler.read() d_text = json.loads(text) for k, v in d_text.items(): print k, v 如果运行正确，那么代码应该返回： 1 2 3 4 5 6 7 issues_url https://api.github.com/issues current_user_repositories_url https://api.github.com/user/repos{?type,page,per_page,sort} rate_limit_url https://api.github.com/rate_limit repository_url https://api.github.com/repos/{owner}/{repo} ... user_repositories_url https://api.github.com/users/{user}/repos{?type,page,per_page,sort} team_url https://api.github.com/teams 同样的效果，用 requests 库则有如下代码： 1 2 3 4 5 6 7 8 9 10 11 import requests cs_url = 'https://api.github.com' cs_user = 'user' cs_psw = 'password' r = requests.get(cs_u

drop table table_name 立刻释放磁盘空间 ，不管是 Innodb和MyISAM ； truncate table table_name立刻释放磁盘空间 ，不管是 Innodb和MyISAM; delete from table_name 删除表的全部数据，对于MyISAM 会立刻释放磁盘空间 ，而InnoDB 不会释放磁盘空间； delete from table_name where xx 带条件的删除, 不管是innodb还是MyISAM都不会释放磁盘空间； delete操作后使用optimize table table_name 释放磁盘空间，优化表期间会锁定表，所以要在空闲时段执行optimize table ，测试十几个G数据的表执行optimize table 大概20多分钟。 注：delete删除数据的时候，mysql并没有把数据文件删除，而是将数据文件的标识位删除，没有整理文件，因此不会彻底释放空间。被删除的数据将会被保存在一个链接清单中，当有新数据写入的时候，mysql会利用这些已删除的空间再写入。即，删除操作会带来一些数据碎片，正是这些碎片在占用硬盘空间。 OPTIMIZE TABLE命令优化表，该命令会重新利用未使用的空间，并整理数据文件的碎片；该命令将会整理表数据和相关的索引数据的物理存储空间，用来减少占用的磁盘空间，并提高访问表时候的IO性能；但是具体对表产生的影响是依赖于表使用的存储引擎的。该命令对视图无效。 使用optimize table table_name出现Table does not support optimize, doing recreate + analyze instead 的解决办法： innodb的数据库不支持optimize，可以用 ALTER TABLE table.name ENGINE='InnoDB';对旧表以复制的方式新建一个新表，然后删除旧表。操作前最好备份表。 重新启动mysql ，在启动的时候指定–skip-new或者–safe-mode选项来支持optimize功能 再执行optimize table table_name >/usr/local/mysql/bin/mysqladmin -uroot -p shutdown --停止mysql >/usr/local/mysql/bin/mysqld --skip-new & --启动mysql >mysql -uroot -p --在服务器上连接mysql mysql>use db_name; 删除数据并执行了optimize table释放了磁盘空间；optimize命令优化表 不要频繁操作，另外还发现执行optimize命令 Innodb 引擎的数据库下ibtmp1 文件由原来的几个Gy优化成12M了。 但如果数据每天都大量插入，删除数据后不执行optimize table, insert 数据的时候会占用已经删除那部分数据的空间，数据文件所占用的磁盘空间短时间并不会增长，所以要减少数据文件占用磁盘空间，可以对表进行压缩。 作者：扛着煤气去救火 链接：https://www.jianshu.com/p/ebe6ac68099a 来源：简

最近忙于填坑中，周末抽时间继续写分布式架构系列的文章。上一篇文章中讲了两阶段提交协议，它能指导我们如何应对分布式中数据强一致性、事务。前面的文章中提到的给数据带上版本号，版本号是递增的，它是类似MVCC的方式。对并发控制的手段有基于锁、时间戳协议、有效性检查、多粒度、多版本机制(MVCC)。 基于MVCC的分布式事务 实现分布式事务除了使用类似”两阶段提交”协议等方式外，另一种简单高效的方式就是使用MVCC(Multi-version Cocurrent Control，多版本并发控制)技术。MVCC技术最初也是在数据库系统中被提出，但这种思想并不局限于单机的分布式系统，在分布式系统中同样有效。 MVCC简介 顾名思义，MVCC即多个不同版本的数据实现并发控制的技术，其基本思想是为每次事务生成一个新版本的数据，在读数据时选择不同版本的数据即可以实现对事务结果的完整性读取。在使用MVCC时，每个事务都是基于一个已生效的基础版本进行更新，事务可以并行进行，从而可以产生一种图状结构。 如图所示，基础数据的版本号为1，同时产生了两个事务：事务A与事务B。这两个事务都各自对数据进行了一些本地修改(这些修改只有事务自己可见，不影响真正的数据)，之后事务A首先提交，生成数据版本2；基于数据版本2，又发起了事务C，事务C继续提交，生成了数据版本3；最后事务B提交，此时事务B的结果需要与事务C的结果合并，如果数据没有冲突，即事务B没有修改事务A与事务C修改过的变量，那么事务B可以提交，否则事务B提交失败。 MVCC的流程过程非常类似于SVN等版本控制系统的流程，或者说SVN等版本控制系统就是使用的MVCC思想。 事务在基于基础数据版本做本地修改时，为了不影响真正的数据，通常有两种做法，一是将基础数据版本中的数据完全拷贝出来在修改，SVN即使用了这种方法，SVN check out即是拷贝过程；二是每个事务中只记录更新操作，而不记录完整的数据，读取数据时再将更新操作应用到基础版本的数据从而计算出结果，这个过程也类似SVN的增量提交。 分布式MVCC 分布式MVCC的重点不在于并发控制，而在于实现分布式事务。这里首先给出一个简化的分布式事务的问题模型，之后对MVCC的讨论基于该问题展开。假设在一个分布式系统中，更新操作以事务进行，每个事务包含若干个对不同节点的不同更新操作。更新事务必须具有原子性，即事务中的所有更新操作要么同时在各个节点生效，要么都不生效。假设不存在并发的事务，即上一个事务成功提交后才进行下一个事务。 例如，

前言 磁盘可以说是计算机系统最慢的硬件之一，读写速度相差内存 10 倍以上，所以针对优化磁盘的技术非常的多，比如零拷贝、直接 I/O、异步 I/O 等等，这些优化的目的就是为了提高系统的吞吐量，另外操作系统内核中的磁盘高速缓存区，可以有效的减少磁盘的访问次数。 这次，我们就以「文件传输」作为切入点，来分析 I/O 工作方式，以及如何优化传输文件的性能。 正文 为什么要有 DMA 技术? 在没有 DMA 技术前，I/O 的过程是这样的： CPU 发出对应的指令给磁盘控制器，然后返回； 磁盘控制器收到指令后，于是就开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，然后产生一个中断； CPU 收到中断信号后，停下手头的工作，接着把磁盘控制器的缓冲区的数据一次一个字节地读进自己的寄存器，然后再把寄存器里的数据写入到内存，而在数据传输的期间 CPU 是无法执行其他任务的。 为了方便你理解，我画了一副图： 可以看到，整个数据的传输过程，都要需要 CPU 亲自参与搬运数据的过程，而且这个过程，CPU 是不能做其他事情的。 简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用 CPU 来搬运的话，肯定忙不过来。 计算机科学家们发现了事情的严重性后，于是就发明了 DMA 技术，也就是直接内存访问（Direct Memory Access） 技术。 什么是 DMA 技术？简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务。 那使用 DMA 控制器进行数据传输的过程究竟是什么样的呢？下面我们来具体看看。 具体过程： 用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态； 操作系统收到请求后，进一步将 I/O 请求发送 DMA，然后让 CPU 执行其他任务； DMA 进一步将 I/O 请求发送给磁盘； 磁盘收到 DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向 DMA 发起中断信号，告知自己缓冲区已满； DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用 CPU，CPU 可以执行其他任务； 当 DMA 读取了足够多的数据，就会发送中断信号给 CPU； CPU 收到 DMA 的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回； 可以看到， 整个数据传输的过程，CPU 不再参与数据搬运的工作

In this article, we will talk about generating Java code from Swagger files, which are essentially API specification files for a Web Service. Below video discusses this with the demo. Open API In our previous article, we talked about SOAP services. The challenge with SOAP services is that they tend to be heavy because of XML data usage, and there is a very tight coupling between the client and server. With time, REST Web Services have become the de-facto standard for Web Services, because of their extensibility. REST APIs are documented using the Open API specifications. Open API is a specification for machine-readable interface files for describing, producing, consuming and visualizing RESTful Web Services. These were earlier called swagger specifications when they were developed by [SmartBear Software]. Because of a standard specification, APIs created with this have a common structure and it allows to build tooling around the APIs to cut down on the amount of boilerplate code. Let’s see an example Swagger API. Petstore Swagger API Petstore API is the example Swagger API hosted at swagger.io. The API allows you to manage pets in a store. The API can be viewed in the Swagger UI, which gives a very detailed view of the API, the available operations, the request parameters, headers, authorization, response, all of it. It becomes a handy document for reference as well. Swagger-Codegen Since, Swagger API has well-defined structure, it can be used to generate Java classes for Rest API service and get the API integration going in no time. Swagger Codegen is designed for exact same purpose. Its comes as a standalone binary as well as Maven plugin, to generate the code, and that is what we will use for the Petstore API demo. Project The initial project used in this article is available here. Here are the contents of the Project -> tree . . ├── pom.xml └── src ├── main │   ├── java │   └── resources └── test ├── java