Linux多線程服務端編程

所属分类:編程語言與程序設計  
出版时间:2013-1-15   出版时间:電子工業出版社   作者:陳碩   页数:616  

前言

本書主要講述采用現代C++ 在x86-64 Linux上編寫多線程TCP網絡服務程序的主流常規技術,這也是我對過去5年編寫生產環境下的多線程服務端程序的經驗總結。本書重點講解多線程網絡服務器的一種IO 模型,即one loop per thread。這是一種適應性較強的模型,也是Linux 下以native語言編寫用戶態高性能網絡程序最成熟的模式,掌握之後可順利地開發各類常見的服務端網絡應用程序。本書以muduo網絡庫為例,講解這種編程模型的使用方法及注意事項。muduo 是一個基于非阻塞IO 和事件驅動的現代C++ 網絡庫,原生支持oneloop per thread 這種IO 模型。muduo 適合開發Linux 下的面向業務的多線程服務端網絡應用程序,其中“面向業務的網絡編程”的定義見附錄A。“現代C++”指的不是C++11 新標準,而是2005 年TR1 發布之後的C++ 語言和庫。與傳統C++ 相比,現代C++ 的變化主要有兩方面︰資源管理(見第1 章)與事件回調(見第449 頁)。本書不是多線程編程教程,也不是網絡編程教程,更不是C++教程。讀者應該已經大致讀過《UNIX環境高級編程》、《UNIX網絡編程》、《C++Primer》或與之內容相近的書籍。本書不談C++11,因為目前(2012年)主流的Linux 服務端發行版的g++版本都還停留在4.4,C++11 進入實用尚需一段時日。本書適用的硬件環境是主流x86-64 服務器,多路多核CPU、幾十GB 內存、千兆以太網互聯。除了第5章講診斷日志之外,本書不涉及文件IO。本書分為四大部分,第1 部分“C++ 多線程系統編程”考察多線程下的對象生命期管理、線程同步方法、多線程與C++ 的結合、高效的多線程日志等。第2 部分“muduo 網絡庫”介紹使用現成的非阻塞網絡庫編寫網絡應用程序的方法,以及muduo的設計與實現。第3部分“工程實踐經驗談”介紹分布式系統的工程化開發方法和C++在工程實踐中的功能特性取舍。第4部分“附錄”分享網絡編程和C++語言的學習經驗。本書的宗旨是貴精不貴多。掌握兩種基本的同步原語就可以滿足各種多線程同步的功能需求,還能寫出更易用的同步設施。掌握一種進程間通信方式和一種多線程網絡編程模型就足以應對日常開發任務,編寫運行于公司內網環境的分布式服務系統。(本書不涉及分布式存儲系統,也不涉及UDP。)術語與排版範例本書大量使用英文術語,甚至有少量英文引文。設計模式的名字一律用英文,例如Observer、Reactor、Singleton。在中文術語不夠突出時,也會使用英文,例如class、heap、event loop、STLalgorithm等。注意幾個中文C++術語︰對象實體(instance)、函數重載決議(resolution)、模板具現化(instantiation)、覆寫(override)虛函數、提領(dereference)指針。本書中的英語可數名詞一般不用復數形式,例如兩個class,6 個syscall;但有時會用(s) 強調中文名詞是復數。fd 是文件描述符(file descriptor)的縮寫。“CPU數目”一般指的是核(core)的數目。容量單位kB、MB、GB表示的字節數分別為103、106、109,在特別強調準確數值時,會分別用KiB、MiB、GiB 表示210、220、230 字節。用諸如§11.5 表示本書第11.5 節,L42 表示上下文中出現的第42 行代碼。[JCP]、[CC2e] 等是參考文獻,見書末清單。

内容概要

  《Linux多線程服務端編程︰使用muduo C++網絡庫》主要講述采用現代C++在x86-64 Linux上編寫多線程TCP網絡服務程序的主流常規技術,重點講解一種適應性較強的多線程服務器的編程模型,即one loop per thread。這是在Linux下以native語言編寫用戶態高性能網絡程序最成熟的模式,掌握之後可順利地開發各類常見的服務端網絡應用程序。本書以muduo網絡庫為例,講解這種編程模型的使用方法及注意事項。  《Linux多線程服務端編程︰使用muduo C++網絡庫》的宗旨是貴精不貴多。掌握兩種基本的同步原語就可以滿足各種多線程同步的功能需求,還能寫出更易用的同步設施。掌握一種進程間通信方式和一種多線程網絡編程模型就足以應對日常開發任務,編寫運行于公司內網環境的分布式服務系統。

作者简介

陳碩,北京師範大學碩士,擅長C++多線程網絡編程和實時分布式系統架構。曾在摩根士丹利IT部門工作5年,從事實時外匯交易系統開發。現在在美國加州 谷某互聯網大公司工作,從事大規模分布式系統的可靠性工程。編寫了開源C++網絡庫muduo,參與翻譯了《代碼大全(第2版)》和《C++編程規範(繁體版)》,整理了《C++ Primer(第4版)(評注版)》,並曾多次在各地技術大會演講。

书籍目录

第1部分 C++多线程系统编程 第1章 线程安全的对象生命期管理 1.1 当析构函数遇到多线程 1.1.1 线程安全的定义 1.1.2 MutexLock与HutexLockGuard 1.1.3 一个线程安全的Counter示例 1.2 对象的创建很简单 1.3 销毁太难 1.3.1 mutex不是办法 1.3.2 作为数据成员的mutex不能保护析构 1.4 线程安全的Observer有多难 1.5 原始指针有何不妥 1.6 神器shared_ptr/weak_ptr 1.7 插曲:系统地避免各种指针错误 1.8 应用到Observer上 1.9 再论shared_ptr的线程安全 1.10 shared_ptr技术与陷阱 1.11 对象池 1.11.1 enable_shared_from_this 1.11.2 弱回调 1.12 替代方案 1.13 心得与小结 1.14 Observer之谬 第2章 线程同步精要 2.1 互斥器(mutex) 2.1.1 只使用非递归的mutex 2.1.2 死锁 2.2 条件变量(condition variable) 2.3 不要用读写锁和信号量 2.4 封装MutexLock、MutexLockGuard、Condition 2.5 线程安全的Singleton实现 2.6 sleep(3)不是同步原语 2.7 归纳与总结 2.8 借shared_ptr实现copy-on-write 第3章 多线程服务器的适用场合与常用编程模型 3.1 进程与线程 3.2 单线程服务器的常用编程模型 3.3 多线程服务器的常用编程模型 3.3.1 one loop per thread 3.3.2 线程池 3.3.3 推荐模式 3.4 进程间通信只用TCP 3.5 多线程服务器的适用场合 3.5.1 必须用单线程的场合 3.5.2 单线程程序的优缺点 3.5.3 适用多线程程序的场景 3.6 “多线程服务器的适用场合”例释与答疑 第4章 C++多线程系统编程精要 4.1 基本线程原语的选用 4.2 C/C++系统库的线程安全性 4.3 Linux上的线程标识 4.4 线程的创建与销毁的守则 4.4.1 pthread_cancel与C++ 4.4.2 exit(3)在C++中不是线程安全的 4.5 善用__thread关键字 4.6 多线程与IO Linux多线程服务端编程:使用muduo C++网络库 4.7 用RAII包装文件描述符 4.8 RAII与fork() 4.9 多线程与fork() 4.10 多线程与signal 4.11 Linux新增系统调用的启示 第5章 高效的多线程日志 5.1 功能需求 5.2 性能需求 5.3 多线程异步日志 5.4 其他方案 第2部分 muduo网络库 第6章 muduo网络库简介 6.1 由来 6.2 安装 6.3 目录结构 6.3.1 代码结构 6.3.2 例子 6.3.3 线程模型 6.4 使用教程 6.4.1 TCP网络编程本质论 6.4.2 echo服务的实现 6.4.3 七步实现finger服务 6.5 性能评测 6.5.1 muduo与Boost.Asio、libevent2的吞吐量对比 6.5.2 击鼓传花:对比muduo与libevent2的事件处理效率 6.5.3 muduo与Nginx的吞吐量对比 6.5.4 muduo与ZeroMQ的延迟对比 6.6 详解muduo多线程模型 6.6.1 数独求解服务器 6.6.2 常见的并发网络服务程序设计方案 Linux多线程服务端编程:使用muduo C++网络库 第7章 muduo编程示例 7.1 五个简单TCP示例 7.2 文件传输 7.3 Boost.Asio的聊天服务器 7.3.1 TCP分包 7.3.2 消息格式 7.3.3 编解码器LengthHeaderCodec 7.3.4 服务端的实现 7.3.5 客户端的实现 7.4 muduo Buffer类的设计与使用 7.4.1 muduo的IO模型 7.4.2 为什么non-blocking网络编程中应用层buffer是必需的 7.4.3 Buffer的功能需求 7.4.4 Buffer的数据结构 7.4.5 Buffer的操作 7.4.6 其他设计方案 7.4.7 性能是不是问题 7.5 一种自动反射消息类型的Google Protobuf网络传输方案 7.5.1 网络编程中使用Protobuf的两个先决条件 7.5.2 根据type name反射自动创建Message对象 7.5.3 Protobuf传输格式 7.6 在muduo中实现Protobuf编解码器与消息分发器 7.6.1 什么是编解码器(codec) 7.6.2 实现ProtobufCodec 7.6.3 消息分发器(dispatcher)有什么用 7.6.4 ProtobufCodec与ProtobufDispatcher的综合运用 7.6.5 ProtobufDispatcher的两种实现 7.6.6 ProtobufCodec和ProtobufDispatcher有何意义 7.7 限制服务器的最大并发连接数 7.7.1 为什么要限制并发连接数 7.7.2 在muduo中限制并发连接数 Linux多线程服务端编程:使用muduo C++网络库 7.8 定时器 7.8.1 程序中的时间 7.8.2 Linux时间函数 7.8.3 muduo的定时器接口 7.8.4 Boost.Asio Timer示例 7.8.5 Java Netty示例 7.9 测量两台机器的网络延迟和时间差 7.10 用timing wheel踢掉空闲连接 7.10.1 timing wheel原理 7.10.2 代码实现与改进 7.11 简单的消息广播服务 7.12 “串并转换”连接服务器及其自动化测试 7.13 socks4a代理服务器 7.13.1 TCP中继器 7.13.2 socks4a代理服务器 7.13.3 N:1与1:N连接转发 7.14 短址服务 7.15 与其他库集成 7.15.1 UDNS 7.15.2 c—ares DNS 7.15.3 curl 7.15.4 更多 …… 第8章 muduo网络库设计与实现 第3部分 工程实践经验谈 第9章 分布式系统工程实践 第10章 C++编译链接模型精要 第11章 反思C++面向对象与虚函数 第12章 C++经验谈 第4部分 附录 附录A 谈一谈网络编程学习经验 附录B 从《C++Primer(第4版)》入手学习C++ 附录C 关于Boost的看法 附录D 关于TCP并发连接的几个思考题与试验 参考文献

章节摘录

版权页:   插图:   谈一谈网络编程学习经验 本文谈一谈我在学习网络编程方面的一些个人经验。“网络编程”这个术语的范围很广,本文指用Sockets API 开发基于TCP/IP 的网络应用程序,具体定义见§A.1.5 “网络编程的各种任务角色”。 受限于本人的经历和经验,本附录的适应范围是: x86-64 Linux 服务端网络编程,直接或间接使用Sockets API。 公司内网。不一定是局域网,但总体位于公司防火墙之内,环境可控。 本文可能不适合: PC 客户端网络编程,程序运行在客户的PC 上,环境多变且不可控。 Windows 网络编程。 面向公网的服务程序。 高性能网络服务器。 本文分两个部分: 1.网络编程的一些“胡思乱想”,以自问自答的形式谈谈我对这一领域的认识。 2.几本必看的书,基本上还是W.Richard Stevents 的那几本。 另外,本文没有特别说明时均暗指TCP 协议,“连接”是“TCP 连接”,“服务端”是“TCP 服务端”。 A.1 网络编程的一些“胡思乱想” 以下大致列出我对网络编程的一些想法,前后无关联。 A.1.1 网络编程是什么 网络编程是什么?是熟练使用Sockets API吗?说实话,在实际项目里我只用过两次Sockets API,其他时候都是使用封装好的网络库。 第一次是2005年在学校做一个羽毛球赛场计分系统:我用C#编写运行在PC上的软件,负责比分的显示;再用C#写了运行在PDA上的计分界面,记分员拿着PDA记录比分;这两部分程序通过TCP协议相互通信。这其实是个简单的分布式系统,体育馆有几片场地,每个场地都有一名拿PDA的记分员,每个场地都有两台显示比分的PC(显示器是42寸平板电视,放在场地的对角,这样两边看台的观众都能看到比分)。这两台PC的功能不完全一样,一台只负责显示当前比分,另一台还要负责与PDA通信,并更新数据库里的比分信息。此外,还有一台PC负责周期性地从数据库读出全部7片场地的比分,显示在体育馆墙上的大屏幕上。这台PC上还运行着一个程序,负责生成比分数据的静态页面,通过FTP上传发布到某门户网站的体育频道。系统中还有一个录入赛程(参赛队、运动员、出场顺序等)数据库的程序,运行在数据库服务器上。算下来整个系统有十来个程序,运行在二十多台设备(PC 和PDA)上,还要考虑可靠性,避免single point of failure。 这是我第一次写实际项目中的网络程序,当时写下来的感觉是像写命令行与用户交互的程序:程序在命令行输出一句提示语,等待客户输入一句话,然后处理客户输入,再输出下一句提示语,如此循环。只不过这里的“客户”不是人,而是另一个程序。在建立好TCP 连接之后,双方的程序都是read/write 循环(为求简单,我用的是blocking 读写),直到有一方断开连接。 第二次是2010 年编写muduo 网络库,我再次拿起了Sockets API,写了一个基于Reactor 模式的C++ 网络库。写这个库的目的之一就是想让日常的网络编程从Sockets API 的琐碎细节中解脱出来,让程序员专注于业务逻辑,把时间用在刀刃上。muduo 网络库的示例代码包含了几十个网络程序,这些示例程序都没有直接使用Sockets API。 在此之外,无论是实习还是工作,虽然我写的程序都会通过TCP 协议与其他程序打交道,但我没有直接使用过Sockets API。对于TCP 网络编程,我认为核心是处理“三个半事件”,见§6.4.1“TCP 网络编程本质论”。程序员的主要工作是在事件处理函数中实现业务逻辑,而不是和Sockets API“较劲”。 这里还是没有说清楚“网络编程”是什么,请继续阅读后文§A.1.5“网络编程的各种任务角色”。 A.1.2 学习网络编程有用吗 以上说的是比较底层的网络编程,程序代码直接面对从TCP 或UDP 收到的数据以及构造数据包发出去。在实际工作中,另一种常见的情况是通过各种client library来与服务端打交道,或者在现成的框架中填空来实现server,或者采用更上层的通信方式。比如用libmemcached 与memcached 打交道,使用libpq 来与PostgreSQL 打交道,编写Servlet 来响应HTTP 请求,使用某种RPC 与其他进程通信,等等。这些情况都会发生网络通信,但不一定算作“网络编程”。如果你的工作是前面列举的这些,学习TCP/IP 网络编程还有用吗? 我认为还是有必要学一学,至少在troubleshooting 的时候有用。无论如何,这些library 或framework 都会调用底层的Sockets API 来实现网络功能。当你的程序遇到一个线上问题时,如果你熟悉Sockets API,那么从strace 不难发现程序卡在哪里,尽管可能你没有直接调用这些Sockets API。另外,熟悉TCP/IP 协议、会用tcpdump 也非常有助于分析解决线上网络服务问题。 A.1.3 在什么平台上学习网络编程 对于服务端网络编程,我建议在Linux 上学习。 如果在10年前,这个问题的答案或许是FreeBSD,因为FreeBSD“根正苗红”,在2000年那一次互联网浪潮中扮演了重要角色,是很多公司首选的免费服务器操作系统。2000 年那会儿Linux 还远未成熟,连epoll 都还没有实现。(FreeBSD 在2001年发布4.1 版,加入了kqueue,从此C10k 不是问题。) 10年后的今天,事情起了一些变化,Linux成为市场份额最大的服务器操作系统。在Linux这种大众系统上学网络编程,遇到什么问题会比较容易解决。因为用的人多,你遇到的问题别人多半也遇到过;同样因为用的人多,如果真的有什么内核bug,很快就会得到修复,至少有work around 的办法。如果用别的系统,可能一个问题发到论坛上半个月都不会有人理。从内核源码的风格看,FreeBSD 更干净整洁,注释到位,但是无奈它的市场份额远不如Linux,学习Linux 是更好的技术投资。 A.1.4 可移植性重要吗 写网络程序要不要考虑移植性?要不要跨平台?这取决于项目需要,如果贵公司做的程序要卖给其他公司,而对方可能使用Windows、Linux、FreeBSD、Solaris、AIX、HP-UX 等等操作系统,这时候当然要考虑移植性。如果编写公司内部的服务器上用的网络程序,那么大可只关注一个平台,比如Linux。因为编写和维护可移植的网络程序的代价相当高,平台间的差异可能远比想象中大,即便是POSIX 系统之间也有不小的差异(比如Linux 没有SO_NOSIGPIPE 选项,Linux 的pipe(2) 是单向的,而FreeBSD 是双向的),错误的返回码也大不一样。 我就不打算把muduo 往Windows 或其他操作系统移植。如果需要编写可移植的网络程序,我宁愿用libevent、libuv、Java Netty 这样现成的库,把“脏活、累活”留给别人。 A.1.5 网络编程的各种任务角色 计算机网络是个big topic,涉及很多人物和角色,既有开发人员,也有运维人员。比方说:公司内部两台机器之间ping 不通,通常由网络运维人员解决,看看是布线有问题还是路由器设置不对;两台机器能ping 通,但是程序连不上,经检查是本机防火墙设置有问题,通常由系统管理员解决;两台机器能连上,但是丢包很严重,发现是网卡或者交换机的网口故障,由硬件维修人员解决;两台机器的程序能连上,但是偶尔发过去的请求得不到响应,通常是程序bug,应该由开发人员解决。 本文主要关心开发人员这一角色。下面简单列出一些我能想到的跟网络打交道的编程任务,其中前三项是面向网络本身,后面几项是在计算机网络之上构建信息系统。 1.开发网络设备,编写防火墙、交换机、路由器的固件(firmware)。 2.开发或移植网卡的驱动。 3.移植或维护TCP/IP 协议栈(特别是在嵌入式系统上)。 4.开发或维护标准的网络协议程序,HTTP、FTP、DNS、SMTP、POP3、NFS。 5.开发标准网络协议的“附加品”,比如HAProxy、squid、varnish 等Web loadbalancer。 6.开发标准或非标准网络服务的客户端库,比如ZooKeeper 客户端库、memcached客户端库。 7.开发与公司业务直接相关的网络服务程序,比如即时聊天软件的后台服务器、网游服务器、金融交易系统、互联网企业用的分布式海量存储、微博发帖的内部广播通知等等。 8.客户端程序中涉及网络的部分,比如邮件客户端中与POP3、SMTP 通信的部分,以及网游的客户端程序中与服务器通信的部分。 本文所指的“网络编程”专指第7 项,即在TCP/IP 协议之上开发业务软件。换句话说,不是用Sockets API 开发muduo 这样的网络库,而是用libevent、muduo、Netty、gevent 这样现成的库开发业务软件,muduo 自带的十几个示例程序是业务软件的代表。 A.1.6 面向业务的网络编程的特点 与通用的网络服务器不同,面向公司业务的专用网络程序有其自身的特点。 业务逻辑比较复杂,而且时常变化 如果写一个HTTP 服务器,在大致实现HTTP 1.1 标准之后,程序的主体功能一般不会有太大的变化,程序员会把时间放在性能调优和bug 修复上。而开发针对公司业务的专用程序时,功能说明书(spec)很可能不如HTTP 1.1 标准那么细致明确。更重要的是,程序是快速演化的。以即时聊天工具的后台服务器为例,可能第一版只支持在线聊天;几个月之后发布第二版,支持离线消息;又过了几个月,第三版支持隐身聊天;随后,第四版支持上传头像;如此等等。这要求程序员能快速响应新的业务需求,公司才能保持竞争力。由于业务时常变化(假设每月一次版本升级),也会降低服务程序连续运行时间的要求。相反,我们要设计一套流程,通过轮流重启服务器来完成平滑升级(§9.2.2)。 不一定需要遵循公认的通信协议标准 比方说网游服务器就没什么协议标准,反正客户端和服务端都是本公司开发的,如果发现目前的协议设计有问题,两边一起改就行了。由于可以自己设计协议,因此我们可以绕开一些性能难点,简化程序结构。比方说,对于多线程的服务程序,如果用短连接TCP 协议,为了优化性能通常要精心设计accept 新连接的机制2,避免惊群并减少上下文切换。但是如果改用长连接,用最简单的单线程accept 就行了。 程序结构没有定论 对于高并发大吞吐的标准网络服务,一般采用单线程事件驱动的方式开发,比如HAProxy、lighttpd 等都是这个模式。但是对于专用的业务系统,其业务逻辑比较复杂,占用较多的CPU 资源,这种单线程事件驱动方式不见得能发挥现在多核处理器的优势。这留给程序员比较大的自由发挥空间,做好了“横扫千军”,做烂了一败涂地。我认为目前one loop per thread 是通用性较高的一种程序结构,能发挥多核的优势,见§3.3 和§6.6。 性能评判的标准不同 如果开发httpd 这样的通用服务,必然会和开源的Nginx、lighttpd 等高性能服务器比较,程序员要投入相当的精力去优化程序,才能在市场上占有一席之地。而面向业务的专用网络程序不一定是IO bound,也不一定有开源的实现以供对比性能,优化方向也可能不同。程序员通常更加注重功能的稳定性与开发的便捷性。性能只要一代比一代强即可。 网络编程起到支撑作用,但不处于主导地位 程序员的主要工作是实现业务逻辑,而不只是实现网络通信协议。这要求程序员深入理解业务。程序的性能瓶颈不一定在网络上,瓶颈有可能是CPU、Disk IO、数据库等,这时优化网络方面的代码并不能提高整体性能。只有对所在的领域有深入的了解,明白各种因素的权衡(trade-off),才能做出一些有针对性的优化。现在的机器上,简单的并发长连接echo服务程序不用特别优化就做到十多万qps,但是如果每个业务请求需要1ms 密集计算,在8 核机器上充其量能达到8000 qps,优化IO 不如去优化业务计算(如果投入产出合算的话)。 A.1.7 几个术语 互联网上的很多“口水战”是由对同一术语的不同理解引起的,比如我写的《多线程服务器的适用场合》3,就曾经被人说是“挂羊头卖狗肉”,因为这篇文章中举的master 例子“根本就算不上是个网络服务器。因为它的瓶颈根本就跟网络无关。” 网络服务器 “网络服务器”这个术语确实含义模糊,到底指硬件还是软件?到底是服务于网络本身的机器(交换机、路由器、防火墙、NAT),还是利用网络为其他人或程序提供服务的机器(打印服务器、文件服务器、邮件服务器)?每个人根据自己熟悉的领域,可能会有不同的解读。比方说,或许有人认为只有支持高并发、高吞吐量的才算是网络服务器。 为了避免无谓的争执,我只用“网络服务程序”或者“网络应用程序”这种含义明确的术语。“开发网络服务程序”通常不会造成误解。 客户端?服务端?在TCP 网络编程中,客户端和服务端很容易区分,主动发起连接的是客户端,被动接受连接的是服务端。当然,这个“客户端”本身也可能是个后台服务程序,HTTP proxy 对HTTP server 来说就是个客户端。 客户端编程?服务端编程?但是“服务端编程”和“客户端编程”就不那么好区分了。比如Web crawler,它会主动发起大量连接,扮演的是HTTP客户端的角色,但似乎应该归入“服务端编程”。又比如写一个HTTP proxy,它既会扮演服务端——被动接受Web browser 发起的连接,也会扮演客户端——主动向HTTP server发起连接,它究竟算服务端还是客户端?我猜大多数人会把它归入服务端编程。 那么究竟如何定义“服务端编程”? 服务端编程需要处理大量并发连接?也许是,也许不是。比如云风在一篇介绍网游服务器的博客4中就谈到,网游中用到的“连接服务器”需要处理大量连接,而“逻辑服务器”只有一个外部连接。那么开发这种网游“逻辑服务器”算服务端编程还是客户端编程呢?又比如机房的服务进程监控软件,并发数跟机器数成正比,至多也就是两三千的并发连接。(再大规模就超出本书的范围了。) 我认为,“服务端网络编程”指的是编写没有用户界面的长期运行的网络程序,程序默默地运行在一台服务器上,通过网络与其他程序打交道,而不必和人打交道。与之对应的是客户端网络程序,要么是短时间运行,比如wget;要么是有用户界面(无论是字符界面还是图形界面)。本文主要谈服务端网络编程。

编辑推荐

《Linux多線程服務端編程:使用muduo C++網絡庫》編輯推薦︰示範在多核時代采用現代C++編寫,多線程TCP網絡服務器的正規做法。

图书封面




    Linux多線程服務端編程下載



用户评论 (总计24条)

 
 

  •     陳碩的博客以前也有看,出了書第一時間就買了現在很多書講的都是非常基礎的東西,非常基礎的模型,但對于商業用的linux服務器編程模式以及需要注意的事項很少提及,這些知識以往大多只能通過博客文章或者實踐中學習,但這本書可以讓初級linux開發者對linux服務器編程有一個新的認識,這和以往的很多書不一樣,不是講基礎的東西,因此需要有一定基礎,例如C++語言、boost庫、linux等
  •     只看了前面的幾章,感覺寫的很好,很多東西自己以前都沒有考慮到。
  •     1.在用C++設計服務器程序方面是獨一無二的佳作2.使用現代C++的方法
  •     本書是作者對自己blog的整理,侃侃而談,說了不少初學者會遇到的困惑和他自己對C++網絡編程的經驗和認識,國內此類書還是比較少的。但是,書還是存在一些問題,作為一本出版的書應該很合理的安排章節內容,而不是直接粘來,前後章節的思路和觀點明顯有差異,內容也有點“散”;很多觀點前作者都說“我認為”,事實上很多“我認為”是很值得商榷的!另外這本書出版時已經是C++11成文1年多了,作者似乎太急了,直接把之前寫的附上,如果能更新到C++11那麼可以更新很多內容,至少第4章要有很大改動。比如說到C++ memory modle,是一提及便繞過,雖然也提了《thread cannot be implemened as a library》一文,但是還能多談談一些細節,而不是直接說諸如“不必擔心”之類的話。還有一些內容在作者的blog評論中都可以看到,不一一細說。順便說下,我用ACE很多年了,ACE並非像作者blog上所說,而我更不認可很多對此博文的評論,都是盲目跟風,程序員要有自己的“編程世界觀”不是遇到一個文筆不錯的就被忽悠,緊接著跟風、吹捧。
  •     1. 這不是講c++語言的,也不是講linux系統.2. 這本書需要有一定c++基礎, 懂一點網絡程序設計,最好有過具體設計經驗.如果滿足上述條件,那麼本書可以在很多方面幫你提升.1. 內存管理.2. 線程安全.3. 網絡傳輸和具體的業務邏輯分離.4. 了解網絡編程的常見模型. 分布式服務器, 客戶端. ...5. 學習書中的例子, 能很好的提高自己.6. 讀書的過程中,看作者旁征博引, 頓時覺得自己該多讀書了.8. .......在買這本書前, 我對網絡編程了解不多, 維護過一個iphone上的股票行情客戶端.痛苦的很, 傳輸和業務纏在一起, 隨意的跨線程調用. 除了問題bug一個比一個難找....看了作者陳碩的博客, 偶遇本書, 提前一個月定了. 後來啃了幾個星期.把muduo移到iphone上, 期間作者對我的一些問題, 給于了耐心的解答.雖然項目還有待測試,但邏輯清晰, 對搞定項目還是有很大信心. 感謝作者. 由于目前還在啃書中, 有些地方還不理解. 多段時間再寫詳細的書評.如果你搞網絡方面的程序設計, 不管是服務器端還是客戶端, 這本書絕對值得一讀.
  •     很棒的書,能學到很多專業知識!
  •     這是本多線程服務器的好書,支持陳碩,速度很快。
  •     書不錯,對編程水平的提高很有幫助
  •     書還行,只是不太適合c++或Linux基礎不好的人
  •     很好!我想要的,以後能用上!
  •     內容很翔實,覆蓋了很多細節問題
  •     如題,很棒的書。以ACE為關鍵字無意中搜到作者的BLOG,很認同作者的技術觀點,慎用繼承,慎用OO。用上std::bind跟std::function後,思考簡單了好多。
  •     但是建議有一定服務端開發經驗的來看!
  •     書內容豐富,有些地方不是很認同。但很多地方用的是圖片。在根本不需要用圖片的地方也用要用圖片。在我的retain屏幕電腦上閱讀體驗一點也不好。
  •     發現缺少一些實踐的例子,純理論的東西太多,看到後面完全看不明白
  •     說實話,庫實現的不錯,書也寫得很好;雖然創新性不強,但工程上借鑒的價值不錯;是一本好書
  •     還沒看!等看完再來評論
  •     印刷質量實在太差...有20頁印刷不清,根本看不清楚
  •     這書不錯,挺不錯的。
  •     了解了很多之前不知道的東西。多線程不是簡單的學習幾個api。實踐中會遇到各種問題。而這本書剛好彌補了純理論書籍的不足。
  •     好書再買一本~
  •     好書,大家看
  •     看不懂,幫人買的
  •     游來游去
 

計算機與互聯網 PDF免费下载,編程語言與程序設計PDF免费下载。 计算机教程网 

计算机教程网 @ 2017