![](https://img-blog.csdnimg.cn/20201014180756913.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
服务器
shenya1314
这个作者很懒,什么都没留下…
展开
-
Windows异步IO四种方式
我们知道,相对于计算机执行的其他操作而言,设备IO(文件、管道、套接字等)是比较慢的。于是在多线程结构中就考虑到采用异步的方式进行设备读写操作,即我们告诉系统对设备的读写数据,而同时应用程序的其他代码继续执行,直到获取设备操作完毕的系统通知。 在进行异步IO时,我们先向系统发出IO请求,操作系统队列化各种IO请求,并在内部完成操作,当系统在处理IO请求时,我们的线程可以返回继续执行原创 2017-02-28 17:27:32 · 3309 阅读 · 0 评论 -
Linux accept()/epoll_wait()惊群问题与解决方案
问题的来源:参考《UNP 第三版》第30章“客户/服务器设计范式”中“30.6 TCP预先派生子进程服务器程序”// 为便于说明问题,代码已简化int main(int argc, char **argv){ int listenfd = Tcp_Listen(); for (int i = 0; i < nchildren; i++){ if ((pi...转载 2018-02-24 23:13:04 · 729 阅读 · 0 评论 -
DBO与DB_OWER
最近读了几篇博客,关于DBO 与DB_OWER ,做下记录DBO是一个默认的权限概念,它将数据库的访问权限抽象,并默认定义出来形成的架构(Schma),DB_OWER是指的具体用户,和所拥有的权限,而他们的区别是角色的性质,角色可以属于默认的架构DBO 也可以是属于DB_OWER,即可用DBO系统级架构,又可用DB_OWER原创 2018-01-28 14:54:43 · 444 阅读 · 0 评论 -
C++任务队列与多线程
很多场合之所以使用C++,一方面是由于C++编译后的native code的高效性能,另一方面是由于C++优秀的并发能力。并行方式有多进程 和多线程之分,本章暂且只讨论多线程,多进程方面的知识会在其他章节具体讨论。多线程是开发C++服务器程序非常重要的基础,如何根据需求具体的设计、分配线程以及线程间的通信,也是服务器程序非常重要的部分,除了能够带来程序的性能提高外,若设计失误,则可能导致程序复杂而转载 2017-07-30 23:13:21 · 2116 阅读 · 0 评论 -
高并发网络编程之epoll详解
在linux 没有实现epoll事件驱动机制之前,我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在大数据、高并发、集群等一些名词唱得火热之年代,select和poll的用武之地越来越有限,风头已经被epoll占尽。本文便来介绍epoll的实现机制,并附带讲解一下select和poll。通过对比其不同的实现机制,真正理解为何epoll能实现高并发。select转载 2017-06-24 13:43:17 · 74943 阅读 · 19 评论 -
std::condition_variable
比较常见的一个使用 std::condition_variable 场合就是线程池的消息队列。逻辑线程(可能多个)将消息推入消息队列,线程池中的工作线程(多个)会从消息队列中取出消息进行处理,如果队列中没有消息则进入睡眠状态等待消息。本文将通过这种消息队列的实现,来分析如何使用 std::condition_variable 以及使用过程中的注意事项。先看下这个消息队列的最终实现:vo原创 2017-06-20 20:00:22 · 491 阅读 · 0 评论 -
linux 内存管理
摘要:本章首先以应用程序开发者的角度审视Linux的进程内存管理,在此基础上逐步深入到内核中讨论系统物理内存管理和内核内存地使用方法。力求从外自内、水到渠成地引导网友分析linux地内存管理与使用。在本章最后我们给出一个内存映射地实例,帮助网友们理解内核内存管理与用户内存管理之间地关系,希望大家最终能驾驭Linux内存管理。前言内存管理一向是所有操作系统书籍不惜笔墨重点讨论的内容,无论转载 2017-06-19 13:16:20 · 321 阅读 · 0 评论 -
linux内核部件分析之——waitqueue与线程的阻塞
当你必须一个复杂的系统,协调系统的方方面面,灵活地支持各种机制和策略,即使很简单的问题也会变得很复杂。Linux绝对就是这样一个复杂的系统。所以我们要理解它,尽量从原理的角度去理解事务的处理流程,尽量避免各种细枝末节的干扰,尽量规避那些足以压垮自己的庞然大物。(尽管细致末节和庞然大物很可能就是linux闪光的地方,但我们还是小心为上。)原理 现在我们来考虑linux中线程的阻转载 2017-06-19 11:25:06 · 1430 阅读 · 0 评论 -
linux阻塞与非阻塞,同步与异步、I/O模型
1. 概念理解 在进行网络编程时,我们常常见到同步(Sync)/异步(Async),阻塞(Block)/非阻塞(Unblock)四种调用方式: 同步: 所谓同步,就是在发出一个功能调用时,在没有得到结果之前,该调用就不返回。也就是必须一件一件事做,等前一件做完了才能做下一件事。 例如普通B/S模式(同步):提交请求->等待服务器处理->处理完毕返回 这个期间客户转载 2017-06-19 11:11:48 · 526 阅读 · 0 评论 -
关于TCP的问题总结
本文章已收录于:计算机网络一. 什么是TCPTCP 协议是一种面向连接的,为不同主机进程间提供可靠数据传输的协议。TCP协议假定其所使用的网络栈下层协议(如IP 协议)是非可靠的,其自身提供机制保证数据的可靠性传输。在目前的网络栈协议族中,在需要提供可靠性数据传输的应用中,TCP协议是首选的,有时也是唯一的选择。TCP 协议是在最早由Cerf和Kahn[1]所提出的有关网络转载 2017-06-19 10:51:20 · 535 阅读 · 0 评论 -
网络中出现TCP、UDP粘包、分包的两点解决办法
粘包产生原因:先说TCP:由于TCP协议本身的机制(面向连接的可靠地协议-三次握手机制)客户端与服务器会维持一个连接(Channel),数据在连接不断开的情况下,可以持续不断地将多个数据包发往服务器,但是如果发送的网络数据包太小,那么他本身会启用Nagle算法(可配置是否启用)对较小的数据包进行合并(基于此,TCP的网络延迟要UDP的高些)然后再发送(超时或者包大小足够)。那么这样的话,服转载 2017-06-19 10:47:51 · 450 阅读 · 0 评论 -
socket,accept函数解析
讨论完后,才发现,自己虽然熟悉socket的编程套路,但是却并不是那么清楚socket的原理,今天就趁这个机会,把有关socket编程的几个疑问给搞清楚吧。 先给出一个典型的TCP/IP通信示意图。 问题一:socket结构体对象究竟是怎样定义的? 我们知道,在使用socket编程之前,需要调用socket函数创建一个socket对象,该函转载 2017-06-03 10:30:53 · 2158 阅读 · 0 评论 -
linux常用信号列表
SIGHUP:本信号在用户终端结束时发出,通常是在终端的控制进程结束时,通知同一会话期内的各个作业,这时他们与控制终端不在关联。比如,登录Linux时,系统会自动分配给登录用户一个控制终端,在这个终端运行的所有程序,包括前台和后台进程组,一般都属于同一个会话。当用户退出时,所有进程组都将收到该信号,这个信号的默认操作是终止进程。此外对于与终端脱离关系的守护进程,这个信号用于通知它重新读取配置文件。转载 2017-06-16 10:55:41 · 372 阅读 · 0 评论 -
关于keeplive
当服务端开启心跳,客户端开启心跳,则当客户端意外断开连接,服务端释放连接,客户端释放连接当服务端关闭心跳,客户端开启心跳,则当客户端意外断开连接,服务端不会知道,资源不会释放。而当客户端再一次向服务端请求连接的时候,服务端才会释放之前的socketlinux :socket 配置 int optval; socklen_t optlen = sizeof(o原创 2017-04-16 15:34:29 · 3663 阅读 · 0 评论 -
为什么直接杀死线程是不好的
我们知道,windows里有个API叫TerminateThread,它可以干掉任何正在欢快小跑的线程。对应的,liunx里则是pthread_cancel(不是 pthread_kill ,这玩意本质是向线程发信号,而不是杀死线程)加上PTHREAD_CANCEL_ASYNCHRONOUS。但是我们同时也看到,不论是哪种方法,在它们的手册里都不推荐我们使用它们。比如微软的 msd转载 2017-03-01 10:20:28 · 1033 阅读 · 0 评论 -
epool惊群问题的一个解决方案(利用SO_REUSEPORT)
在前段时间公司开发的一个项目中,需要使用多个进程监听同一个端口提高性能,这样的需求需要我们解决惊群问题。 在早些时候,我们是不能在多个子进程中listen、bind同一个socket端口的。通常的做法会在主进程中对端口进行listen、bind,然后把它同时扔进每个子进程维护的epool池中。 在这种情况下,当一个客户端请求来到服务端,会导致多个子进程的epool监听同时被唤醒...转载 2018-02-24 23:13:54 · 1235 阅读 · 0 评论