多队列网卡顾名思义就是由原来的单网卡单队列变成了现在的单网卡多队列。多队列网卡是一种技术，最初是用来解决网络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四元组，将一条流总是收到相同的队列。同时触发与该队列绑定的中断。

More...

从事服务端开发，少不了要接触网络编程。epoll 作为 Linux 下高性能网络服务器的必备技术至关重要，nginx、Redis、Skynet 和大部分游戏服务器都使用到这一多路复用技术。

epoll 很重要，但是 epoll 与 select 的区别是什么呢？epoll 高效的原因是什么？

More...

如何构造出成千上百万的攻城士兵，是高并发测试的关键。而传统压力测试工具设计的时候并不是针对高并发测试设计的。针对高并发场景，传统压力测试工具往往自身是性能瓶颈。为适应高并发趋势，我们设计了TCPBurn，用于无状态协议的高并发压力测试，瞬间可以创造出任意多的攻城的精兵猛将。

我们以消息推送服务为例，来模拟海量用户并发场景。千万并发连接测试相关的公开资料很少，据说要达到C10M（千万连接）并发，需要从根本上解决内核自身的问题。我们的实验希望验证linux服务器环境下Nginx能否承受千万连接的考验。

More...

4.安装R

step1：登录R的官方网站
https://www.r-project.org/

More...

在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止于此，它的价值不仅仅存在于技术上，更重要的是改变了以往同步处理消息的思路（比如进行IM消息历史存储时，传统的信息系统作法可能是收到一条消息就马上同步存入数据库，这种作法在小并发量的情况下可以很好的工作，但互联网大并发环境下就是灾难）。

 

MQ消息中间件可以理解一个水池，水池的这头是消息生产者，水池的那头是消息消费者，生产者和消息者无需直接对接，这将带来很多好处：业务解耦、架构分布式化等，生产者和消费者互相完全透明。

但市面上的MQ消息中间件产品很多，作为IM系统中必不可少的一环，我们该如何选型？那么请继续阅读本文。

More...

无论是IM消息通信系统还是客户消息系统，其本质都是一套消息发送与投递系统，或者说是一套网络通信系统，其本质两个词：存储与转发。

推荐：如有兴趣，本文作者的另一篇《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》，适合进行IM群聊架构设计的参考。

More...

要实现一整套能用于大用户量、高并发场景下的IM群聊，技术难度远超IM系统中的其它功能，原因在于：IM群聊消息的实时写扩散特性带来了一系列技术难题。

举个例子：如一个2000人群里，一条普通消息的发出问题，将瞬间写扩散为2000条消息的接收问题，如何保证这些消息的及时、有序、高效地送达，涉及到的技术问题点实在太多，更别说个别场景下万人大群里的炸群消息难题了更别说个别场景下万人大群里的炸群消息难题了。

这也是为什么一般中大型IM系统中，都会将群聊单独拎出来考虑架构的设计，单独有针对性地进行架构优化，从而降低整个系统的设计难度。

本文将分享的是一套生产环境下的IM群聊消息系统的高可用、易伸缩、高并发架构设计实践，属于原创第一手资料，内容较专业，适合有一定IM架构经验的后端程序员阅读。

推荐：如有兴趣，本文作者的另一篇《一套原创分布式即时通讯(IM)系统理论架构方案》，也适合正在进行IM系统架构设计研究的同学阅读。

More...

连接优化需要解决两个核心问题

1. 连接建立耗时较长，导致请求的总时长变长，进而影响用户体验。

2. 在多变的网络环境下，连接建立的过程可能会失败，导致成功率下降，进而影响用户体验。

百度App承载着亿级流量，对于每一个请求都需要追求耗时短，成功率高的体验。从协议角度出发，如何才能做到这一点呢？首先我们来看下建立连接耗时的原理。

More...

网络优化是客户端几大技术方向中公认的一个深度领域，所以百度App给大家带来网络深度优化系列文章，其中包含系列《一》DNS优化，系列《二》连接优化，系列《三》弱网优化，希望对大家在网络方向的学习和实践有所帮助。

百度起家于搜索，整个公司的网络架构和部署都是基于标准的internet协议，目前已经是全栈HTTPS，来到移动互联网时代后，总的基础架构不变，但在客户端上需要做很多优化工作。

DNS（Domain Name System），它的作用是根据域名查出IP地址，它是HTTP协议的前提，只有将域名正确的解析成IP地址后，后面的HTTP流程才能进行，所以一般做网络优化会首选优化DNS。

二、背景

DNS优化核心需要解决的问题有两点：

1.由于DNS劫持或故障造成的服务不可用，进而影响用户体验，影响公司的收入。

2.由于DNS调度不准确导致的性能退化，进而影响用户体验。

百度App承载着亿级流量，每年都会遇到运营商DNS劫持或运营商DNS故障，整体影响非常不好，所以DNS优化刻不容缓，通过下图会更直观的了解运营商劫持或故障的原理。

More...

致性协议中生产环境中应用最多的了。为什么呢？因为他是为 Zookeeper 设计的分布式一致性协议！

一、什么是 ZAB 协议？ ZAB 协议介绍

1、ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。

2、Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议。

3、ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。下面我们会重点讲这两个东西。

4、基于该协议，Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间 数据一致性。具体如下图所示：

More...