下面说一下猫盘刷了群晖之后怎么安装常用的下载软件吧，这个方法除了猫盘以外，应该也可以在其他ARM版群晖上使用。ARM版群晖是没法安装docker的，一般安装软件是依靠群晖的套件中心。
安装transmission的话比较简单，直接在套件中心添加第三方源（http://packages.synocommunity.com），然后就可以直接在套件中心的社群里面找到transmission套件进行安装就可以了。
相比起transmission，个人更喜欢qBittorrent，qBittorrent可以通过修改种子的分类管理下载文件的保存路径，比较方便整理。但是群晖的套件中心中没有qBittorrent，也没有aira2，那应该怎么安装呢？
研究了一下，发现其实ARM版群晖是可以安装entware的，那就可以通过opkg来安装entware软件仓库中的大量软件了，可玩性大增有没有！
Address Sanitizer（ASan）是一个快速的内存错误检测工具。它非常快，只拖慢程序两倍左右（比起Valgrind快多了）。
它包括一个编译器instrumentation模块和一个提供malloc()/free()替代项的运行时库。
从gcc 4.8开始，AddressSanitizer成为gcc的一部分。当然，要获得更好的体验，
最好使用4.9及以上版本，因为gcc 4.8的AddressSanitizer还不完善，最大的缺点是没有符号信息。
C/C++等底层语言在提供强大功能及性能的同时，其灵活的内存访问也带来了各种纠结的问题。如果crash的地方正是内存使用错误的地方，说明你人品好。如果crash的地方内存明显不是consistent的，或者内存管理信息都已被破坏，并且还是随机出现的，那就比较麻烦了。当然，祼看code打log是一个办法，但其效率不是太高，尤其是在运行成本高或重现概率低的情况下。另外，静态检查也是一类方法，有很多工具（lint, cppcheck, klockwork, splint, o, etc.）。但缺点是误报很多，不适合针对性问题。另外好点的一般还要钱。最后，就是动态检查工具。下面介绍几个Linux平台下主要的运行时内存检查工具。绝大多数都是开源免费且支持x86和ARM平台的。
QUIC 传输协议具有 HTTP 传输所需的几个特性，例如流多路复用、每个流的流控制和低延迟连接建立。本文档描述了 HTTP 语义在 QUIC 上的映射。本文档还确定了 QUIC 包含的 HTTP/2 功能，并描述了如何将 HTTP/2 扩展移植到 HTTP/3。
在Linux上做网络应用的性能优化时，一般都会对TCP相关的内核参数进行调节，特别是和缓冲、队列有关的参数。网上搜到的文章会告诉你需要修改哪些参数，但我们经常是知其然而不知其所以然，每次照抄过来后，可能很快就忘记或混淆了它们的含义。本文尝试总结TCP队列缓冲相关的内核参数，从协议栈的角度梳理它们，希望可以更容易的理解和记忆。注意，本文内容均来源于参考文档，没有去读相关的内核源码做验证，不能保证内容严谨正确。作为Java程序员没读过内核源码是硬伤。
下面我以server端为视角，从 连接建立、 数据包接收 和 数据包发送 这3条路径对参数进行归类梳理。
关于开源图书有热心的伙伴和网友在网络上做了大量整理，本文为大家刊载免费编程类中文开源电子书合集全集，转载自 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系统架构设计研究的同学阅读。