关于开源图书有热心的伙伴和网友在网络上做了大量整理，本文为大家刊载免费编程类中文开源电子书合集全集，转载自 LinuxStory
暂无同学编辑和校对的文章 https://linuxstory.org/free-chinese-programming-books/，(原始 GitHub 地址：https://github.com/justjavac/free-programming-books-zh_CN）转载的原因是未来开源工场的小伙伴会就这个 repo 和话题做更加细致的整理，包括技术类、非技术类等等，希望帮到更多的小伙伴。如果你有兴趣一起做这件事情，请考虑联系工场电报群管理员或者 QQ 群群主。
书山有路勤为径，学海无涯苦作舟！
开源不仅局限于软件领域，开源同样意味着自由选择的权利和对知识开放的追求
下面就来探讨下常见的SFU开源解决方案，当然，你也可以自己实现 SFU 流媒体服务器，但自已实现流媒体服务器困难还是蛮多的，它里面至少要涉及到 DTLS 协议、ICE 协议、SRTP/SRTCP 协议等，光理解这些协议就要花不少的时间，更何况要实现它了。
所以最常见的办法就是使用开源的实现。但是这里我也想给大家说一定，用了开源的解决方案，能快速的搭建起业务，但是无疑也欠下了技术债，因为开源的解决方案肯定没有自己实现的要熟悉，因为不熟悉很多时候出现了问题，并不能马上解决，甚至解决不了，导致业务受到影响。而且熟悉开源解决方案都是需要一个时间和过程的，而一般领导会不会给你这个时间就两说了。
但如果你要快速的搭建起音视频系统的话，无疑使用开源技术解决方案是最快，最能节省人力成本的。下面我们就来分析下常见的SFU开源解决方案的优缺点，以便你选择合适的开源解决方案。
本文从百亿流量交易系统微服务网关（API Gateway）的现状和面临的问题出发，阐述微服务架构与 API 网关的关系，理顺流量网关与业务网关的脉络，分享API网关知识与经验。
“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。”
——David Wheeler
分布式服务架构、微服务架构与 API 网关
1. 什么是API网关（API Gateway）
其实，网关跟面向服务架构（Service Oriented Architecture，SOA）和微服务架构（MicroServicesArchitecture，MSA）有很深的渊源。
十多年以前，银行等金融机构完成全国业务系统大集中以后，分散的系统都变得集中，也带来了各种问题：业务发展过快如何应对，对接系统过多如何集成和管理。为了解决这些问题，业界实现了作用于渠道与业务系统之间的中间层网关，即综合前置系统，由其适配各类渠道和业务，处理各种协议接入、路由与报文转换、同步异步调用等操作，如图7-1所示。
图7-1
人们基于SOA的理念，在综合前置的基础上，进一步增加了服务的元数据管理、注册、中介、编排、治理等功能，逐渐形成了企业服务总线（ESB，EnterpriseService Bus）。例如普元公司推出的PrimetonESB就是一个由本书作者之一参与开发的总线系统，如图7-2所示。
早年间， ⽀持多个⽤户并发访问的服务应⽤，往往采⽤多进程⽅式，即针对每⼀个 TCP ⽹络连接创建⼀个服务进程。在 2000 年左右，⽐较流⾏使⽤ CGI ⽅式编写 Web 服务，当时⼈们⽤的⽐较多的 Web 服务器是基于多进程模式开发的 Apache1.3.x 系列，因为进程占⽤系统资源较多，所以⼈们开始使⽤多线程⽅式编写 Web 应用服务，线程占⽤的资源更少，这使单台服务器⽀撑的⽤户并发度提⾼了，但依然存在资源浪费的问题。因为在多进程或多线程编程⽅式下，均采⽤了阻塞通信⽅式，对于慢连接请求，会使服务端的进程或线程因『等待』客户端的请求数据⽽不能做别的事情，⽩⽩浪费了操作系统的调度时间和系统资源。这种⼀对⼀的服务⽅式在⼴域⽹的环境下显示变得不够廉价，于是⼈们开始采⽤⾮阻塞⽹络编程⽅式来提升服务端网络并发度，⽐较著名的 Web 服务器 Nginx 就是⾮阻塞通信服务的典型代表，另外还有象 Java Netty 这样的⾮阻塞⽹络开发库。
⾮阻塞⽹络编程⼀直以⾼并发和⾼难度⽽著称，这种编程⽅式虽然有效的提升了服务器的利⽤率和处理能力，但却对⼴⼤程序员提出了较⼤挑战，因为⾮阻塞 IO 的编程⽅式往往会把业务逻辑分隔的⽀离破碎，需要在通信过程中记录⼤量的中间状态，⽽且还需要处理各种异常情况，最终带来的后果就是开发周期⻓、复杂度⾼，⽽且难于维护。
阻塞式⽹络编程实现容易但并发度不⾼，⾮阻塞⽹络编程并发度⾼但编写难，针对这两种⽹络编程⽅式的优缺点，⼈们提出了使⽤协程⽅式编写⽹络程序的思想。其实协程本身并不是⼀个新概念，早在2000年前Windows NT 上就出现了『纤程』的 API，号称可以创建成千上万个纤程来处理业务，在 BSD Unix 上可以⽤来实现协程切换的 API <ucontext.h> 在 2002 年就已经存在了，当然另外⽤于上下⽂跳转的 API<setjmp.h> 出现的更早（1993年）。虽然协程的概念出现的较早，但⼈们终不能发现其广泛的应⽤场景，象『longjmp』这些 API 多⽤在⼀些异常跳转上，如 Postfix（著名的邮件MTA）在处理⽹络异常时⽤其实现程序跳转。直到 Russ Cox 在 Go 语⾔中加⼊了协程（Goroutine）的功能，使⽤协程进⾏⾼并发⽹络编程才变得的简单易⾏。
Russ Cox 早在 2002 年就编写了⼀个简单的⽹络协程库 libtask（https://swtch.com/libtask/ ），代码量不多，却可以使我们⽐较清晰地看到『通过使⽹络 IO 协程化，使编写⾼并发⽹络程序变得如此简单』。
MySQL作为当下最流行的开源关系型数据库，有一个很关键和基本的能力，就是必须能够保证数据不会丢。那么在这个能力背后，MySQL是如何设计才能保证不管在什么时间崩溃，恢复后都能保证数据不会丢呢？有哪些关键技术支撑了这个能力？本文将为我们一一揭晓。
MySQL 保证数据不会丢的能力主要体现在两方面：
对于第一点将MySQL恢复到任何时间点的状态，相信很多人都知道，只要保留有足够的binlog，就能通过重跑binlog来实现。
对于第二点的能力，也就是本文标题所讲的crash-safe。即在 InnoDB 存储引擎中，事务提交过程中任何阶段，MySQL突然奔溃，重启后都能保证事务的完整性，已提交的数据不会丢失，未提交完整的数据会自动进行回滚。这个能力依赖的就是redo log和unod log两个日志。
收集部分资料
SRS4的DEMO
FFMPEG 可以使用下面的参数进行基本信息查询。例如，想查询一下现在使用的 FFMPEG 都支持哪些 filter，就可以用 ffmpeg -filters 来查询。详细参数说明如下：
参数 说明
-version 显示版本。
-formats 显示可用的格式（包括设备）。
-demuxers 显示可用的demuxers。
-muxers 显示可用的muxers。
-devices 显示可用的设备。
-codecs 显示libavcodec已知的所有编解码器。
-decoders 显示可用的解码器。
-encoders 显示所有可用的编码器。
-bsfs 显示可用的比特流filter。
-protocols 显示可用的协议。
-filters 显示可用的libavfilter过滤器。
-pix_fmts 显示可用的像素格式。
-sample_fmts 显示可用的采样格式。
-layouts 显示channel名称和标准channel布局。
-colors 显示识别的颜色名称。
作者先简单介绍 Redis 6 会给大家提供的新功能，包括：
一、对用户使用有直接影响的功能
二、Redis 内部的优化
三、外部工具
Sysdig是一个全面的开源系统活动监控，捕获和分析应用程序。它具有强大的过滤语言和可自定义的输出，以及可以使用称为chisels 的Lua脚本扩展的核心功能。
应用程序通过访问内核来工作， 内核允许它查看每个系统调用以及通过内核传递的所有信息。这也使其成为监视和分析系统上运行的应用程序容器生成的系统活动和事件的出色工具。
核心Sysdig应用程序监视其安装的服务器。但是，该项目背后的公司提供了一个名为Sysdig Cloud的托管版本，可以远程监控任意数量的服务器。
独立应用程序可在大多数Linux发行版上使用，但在Windows和macOS上也可用，功能更为有限。除了sysdig命令行工具，Sysdig还带有一个csysdig带有类似选项的交互式UI 。
在本教程中，您将安装并使用Sysdig来监视Ubuntu 16.04服务器。您将流式传输实时事件，将事件保存到文件，过滤结果以及浏览csysdig交互式UI。
最近很多朋友跟我抱怨：为了公司数据好看，老板一个劲地想要数据可视化，以为可视化就是画画图表这么简单，可苦了自己天天加班做数据，但其实老板根本不懂可视化！
确实，数据可视化无疑是当今最火热的词，不管是做什么数据，似乎都要拿来做一下可视化才行，但很多人都对数据可视化没有一个具体的概念，也不知道该如何实现可视化。所以，话不多说，下面就带大家由浅入深地学习数据可视化的定义、概念、实现过程和方法。
科学可视化、 信息可视化和可视分析学三个学科方向通常被看成可视化的三个主要分支。而将这三个分支整合在一起形成的新学科 “数据可视化”，这是可视化研究领域的新起点。
广义的数据可视化涉及信息技术、自然科学、统计分析、图形学、交互、地理信息等多种学科。
好的数据库规范有助于减少软件实现的复杂度，降低沟通成本，本铁律主要涵盖了建库建表、建索引、写 SQL、ORM 映射等方面的处理约定。
这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。
相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。
介绍分布式事务之前，先介绍什么是事务。
事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。
简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。
多队列网卡顾名思义就是由原来的单网卡单队列变成了现在的单网卡多队列。多队列网卡是一种技术，最初是用来解决网络IO QoS （quality of service）问题的，后来随着网络IO的带宽的不断提升，单核CPU不能完全处满足网卡的需求，体现最为明显的就是单核CPU处理不了网卡大量的数据包请求（软中断）而造成大量丢包，其实当网卡收到数据包时会产生中断，通知内核有新数据包，然后内核调用中断处理程序进行响应，把数据包从网卡缓存拷贝到内存，因为网卡缓存大小有限，如果不及时拷出数据，后续数据包将会因为缓存溢出被丢弃，因此这一工作需要立即完成。剩下的处理和操作数据包的工作就会交给软中断，高负载的网卡是软中断产生的大户，很容易形成瓶颈。但通过多队列网卡驱动的支持，将各个队列通过中断绑定到不同的CPU核上，以满足网卡的需求，这就是多队列网卡的应用。
常见的有Intel的82575、82576，Boardcom的57711等，下面以公司的服务器使用较多的Intel 82575网卡为例，分析一下多队列网卡的硬件的实现以及Linux内核软件的支持。
一、多队列网卡硬件实现
图1.1是Intel 82575硬件逻辑图，有四个硬件队列。当收到报文时，通过hash包头的SIP、Sport、DIP、Dport四元组，将一条流总是收到相同的队列。同时触发与该队列绑定的中断。
从事服务端开发，少不了要接触网络编程。epoll 作为 Linux 下高性能网络服务器的必备技术至关重要，nginx、Redis、Skynet 和大部分游戏服务器都使用到这一多路复用技术。
epoll 很重要，但是 epoll 与 select 的区别是什么呢？epoll 高效的原因是什么？
如何构造出成千上百万的攻城士兵，是高并发测试的关键。而传统压力测试工具设计的时候并不是针对高并发测试设计的。针对高并发场景，传统压力测试工具往往自身是性能瓶颈。为适应高并发趋势，我们设计了TCPBurn，用于无状态协议的高并发压力测试，瞬间可以创造出任意多的攻城的精兵猛将。
我们以消息推送服务为例，来模拟海量用户并发场景。千万并发连接测试相关的公开资料很少，据说要达到C10M（千万连接）并发，需要从根本上解决内核自身的问题。我们的实验希望验证linux服务器环境下Nginx能否承受千万连接的考验。
4.安装R
step1：登录R的官方网站
https://www.r-project.org/
5.安装RStudio
step1：打开RStudio官方网站 https://www.rstudio.com/products/rstudio/download/ 点击Free下的Download
在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止于此，它的价值不仅仅存在于技术上，更重要的是改变了以往同步处理消息的思路（比如进行IM消息历史存储时，传统的信息系统作法可能是收到一条消息就马上同步存入数据库，这种作法在小并发量的情况下可以很好的工作，但互联网大并发环境下就是灾难）。
MQ消息中间件可以理解一个水池，水池的这头是消息生产者，水池的那头是消息消费者，生产者和消息者无需直接对接，这将带来很多好处：业务解耦、架构分布式化等，生产者和消费者互相完全透明。
但市面上的MQ消息中间件产品很多，作为IM系统中必不可少的一环，我们该如何选型？那么请继续阅读本文。
无论是IM消息通信系统还是客户消息系统，其本质都是一套消息发送与投递系统，或者说是一套网络通信系统，其本质两个词：存储与转发。
推荐：如有兴趣，本文作者的另一篇《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》，适合进行IM群聊架构设计的参考。
要实现一整套能用于大用户量、高并发场景下的IM群聊，技术难度远超IM系统中的其它功能，原因在于：IM群聊消息的实时写扩散特性带来了一系列技术难题。
举个例子：如一个2000人群里，一条普通消息的发出问题，将瞬间写扩散为2000条消息的接收问题，如何保证这些消息的及时、有序、高效地送达，涉及到的技术问题点实在太多，更别说个别场景下万人大群里的炸群消息难题了更别说个别场景下万人大群里的炸群消息难题了。
这也是为什么一般中大型IM系统中，都会将群聊单独拎出来考虑架构的设计，单独有针对性地进行架构优化，从而降低整个系统的设计难度。
本文将分享的是一套生产环境下的IM群聊消息系统的高可用、易伸缩、高并发架构设计实践，属于原创第一手资料，内容较专业，适合有一定IM架构经验的后端程序员阅读。
推荐：如有兴趣，本文作者的另一篇《一套原创分布式即时通讯(IM)系统理论架构方案》，也适合正在进行IM系统架构设计研究的同学阅读。
连接优化需要解决两个核心问题
1. 连接建立耗时较长，导致请求的总时长变长，进而影响用户体验。
2. 在多变的网络环境下，连接建立的过程可能会失败，导致成功率下降，进而影响用户体验。
百度App承载着亿级流量，对于每一个请求都需要追求耗时短，成功率高的体验。从协议角度出发，如何才能做到这一点呢？首先我们来看下建立连接耗时的原理。
网络优化是客户端几大技术方向中公认的一个深度领域，所以百度App给大家带来网络深度优化系列文章，其中包含系列《一》DNS优化，系列《二》连接优化，系列《三》弱网优化，希望对大家在网络方向的学习和实践有所帮助。
百度起家于搜索，整个公司的网络架构和部署都是基于标准的internet协议，目前已经是全栈HTTPS，来到移动互联网时代后，总的基础架构不变，但在客户端上需要做很多优化工作。
DNS（Domain Name System），它的作用是根据域名查出IP地址，它是HTTP协议的前提，只有将域名正确的解析成IP地址后，后面的HTTP流程才能进行，所以一般做网络优化会首选优化DNS。
二、背景
DNS优化核心需要解决的问题有两点：
1.由于DNS劫持或故障造成的服务不可用，进而影响用户体验，影响公司的收入。
2.由于DNS调度不准确导致的性能退化，进而影响用户体验。
百度App承载着亿级流量，每年都会遇到运营商DNS劫持或运营商DNS故障，整体影响非常不好，所以DNS优化刻不容缓，通过下图会更直观的了解运营商劫持或故障的原理。
致性协议中生产环境中应用最多的了。为什么呢？因为他是为 Zookeeper 设计的分布式一致性协议！
1、ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。
2、Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议。
3、ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。下面我们会重点讲这两个东西。
4、基于该协议，Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间 数据一致性。具体如下图所示：
ODBC 是Open Database Connect 即开放数据库互连的简称，它是由Microsoft 公司于1991 年提出的一个用于访问数据库的统一界面标准，是应用程序和数据库系统之间的中间件。它通过使用相应应用平台上和所需数据库对应的驱动程序与应用程序的交互来实现对数据库的操作，避免了在应用程序中直接调用与数据库相关的操作，从而提供了数据库的独立性。
ODBC 主要由驱动程序和驱动程序管理器组成。驱动程序是一个用以支持ODBC 函数调用的模块，每个驱动程序对应于相应的数据库，当应用程序从基于一个数据库系统移植到另一个时，只需更改应用程序中由ODBC 管理程序设定的与相应数据库系统对应的别名即可。驱动程序管理器可链接到所有ODBC 应用程序中，它负责管理应用程序中ODBC 函数与DLL 中函数的绑定。
ODBC 使用层次的方法来管理数据库，在数据库通信结构的每一层，对可能出现依赖数据库产品自身特性的地方，ODBC 都引入一个公共接口以解决潜在的不一致性，从而很好地解决了基于数据库系统应用程序的相对独立性，这也是ODBC 一经推出就获得巨大成功的重要原因之一。
从结构上分，ODBC 分为单束式和多束式两类。
很多程序员已经体会到了在Windows平台下的ODBC的益处，而在Linux/Unix下进行数据库编程的时候却不得不根据不同的数据库来选择特有的API进行编程，一旦数据库发生了改变，所有与这些API相关的程序都必须进行修改。其实在Linux/Unix下现在也有了自己的ODBC，可以使我们的数据库编程就像在Windows平台下一样简单。
很多场景我们编译C源码，都需要使用gcc4.8及以上版本，比如编译MySQL 8.0、GRPC等，原因是需要支持C++11。但CentOS 6其内置版本是gcc4.4。
使用
gcc --version可以查看版本。
编译问题整理
Valgrind是一组调试(debugging)和剖析(profiling)工具的集合。memcheck是其中应用最广泛的一个，它检查内存有关的问题，包括诸如内存访问越界、内存泄露等。