supdriver的博客

服务端详细设计版本信息当前版本: v0.9测试版 当前版本的服务器使用了如下技术栈: QT框架: 利用QT的全平台特性，这里的开发环境也使用了QT框架。主要使用了QT里的数据结构 QT Json框架: 本版本对报文的序列化与反序列化技术依然使用了Json格式 cpp-httplib:一个开源的单文件的http库，用于提供简单易操作的短链接HTTP服务 MySQL Connector/C++ Windows平台: MySQL官方提供的Windows平台C++连接数据库的API HTTP请求路径约定客户端与服务端的交互对具体函数的调用，取决于HTTP 请求路径的约定，所以要提前约定好 账户相关 Account API 路径 业务 /account/register 账户注册 /account/login/username 账户使用用户名登录 /account/login/phone 账户使用手机号登录 /account/update/level 消费者账户优惠等级更新 /account/update/nickname 账号更新昵称 消费者相关 Consu ...

模式名称: 组合模式类型: 结构型问题-使用场景: 可用于构建对象树这样的部分-整体层次结构，使用户对单个对象和组合对象的使用具有一致性解决方案: 使用递归组合的方式构建类效果: 使用户对单个对象和组合对象的使用具有一致性 样例引入如下图，有过QT开发经验的朋友能够看出来，这是QT组件管理里的对象树，它是一种管理组件的数据结构，同时它也很好地体现了组合模式在实际应用中的作用。 实现方式我们可以通过继承和聚合配合使用的方式实现组合模式，就以模拟实现上图的QWidget为例，我们来设计一个自己SWidget使之能够达到类似的效果 我们设计的类图如下 可以看到，在类图中，SObject和SWidget既是继承关系，又有组合关系,这一结构特点使SWidget之间能够构成对象树，而SLabel也是SObject的子类，但由于没有聚合关系，所以SLabel在对象树中仅能作为”叶子节点”存在。 代码实现如下，我们成功构建了一颗三层的对象树。 1234567891011121314151617181920212223242526272829303132333435363738394041424 ...

模式名称: 适配器-Adapter,又称包装器-Wrapper类型: 结构型问题-使用场景: 适配器可以让原本由于接口不兼容而不能一起工作的类可以重新一起工作解决方案：使用适配器对象对原本的类进行继承或者对类的对象进行组合并调用接口两种方式效果：在无需知晓，且不改变已有类的源码的前提下,使系统能够耦合在一起进行工作 实现方式Adapter主要有两种实现方式。 继承 组合 两种方式各有利弊，虽然可能组合方式居多 应用举例现在我们要做一个绘图编辑器，我们用Shape抽象类规定了子类控件的行为，而我们又有了一个成品的工具类TextView，它本身提供了显示文本的接口,但我们不知道它的源码，或者不愿意修改它的源码，因此我们无法让TextView满足Shape的规定接口要求，二者无法直接一起工作。 所以为了复用TextView，我们可以选择使用适配器模式，构造一个TextShape子类继承自Shape，同时组合了一个TextView实例化出的对象text，这样也可以调用TextView里的接口。这样通过TextShape作为适配器，我们成功地让接口能够间接兼容了。 下图为例子的类图， ...

传输层负责接收应用层的数据并通过网络层发送到网络的另一端。主要的传输层协议就是UDP和TCP协议 再谈端口号因为传输层要和网络层打交道，常常要使用IP和端口号，IP协议我们以后再详谈，我们先再深入学习下端口 端口是网络协议中的概念，是一个uint16_t的无符号整型，范围是0~65535，显然还是一个有限资源。 端口号划分 0~1023: 知名端口号，HTTP,FTP,SSH等这些常用的应用层协议会固定使用里面的端口号 1024~65535:操作系统动态分配的端口号。客户端自动分配的端口号就在这个范围。 知名端口号为了方便使用，人们约定了常用的服务器使用固定的端口号 服务器类型 端口号 SSH 22 FTP 21 telnet 23 HTTP 80 HTTPS 443 UDP协议全称 User Datagram Protocol, 即用户数据报协议 格式UDP协议的格式十分简单，就是固定的8字节报头,组成结构如下 UDP长度这一部分的值表示整个报文的长度，单位是字节，包括UDP报头和数据段。16位UDP长度支持的最大长度是64K 然而64KB在如今 ...

本次版本更新我们采用Sink类主题更新,实现数据库落地，按小时按天滚动输出,网络输出,以及标准输出按等级染色 重大bug修复修改前的代码 12345678910void error(const char*file,size_t line,const char*fmt,...){ if(shouldLog(LogLevel::Level::ERROR) == false) return; va_list al; va_start(al,fmt);//依据fmt从内存中提取可变参数列表 log(LogLevel::Level::WARN,file,line,fmt,al);//日志输出 va_end(al);//结束可变参数列表} 可以看到里面的ERROR被错误地写成了WARN,导致输出error等级的日志时会错误输出WARN。因为这一bug涉及到项目的核心功能，所以判定为重大bug。这一重大bug导致前面的版本全都作废 数据库落地这里我们使用部署在云服务器上的MySQL数据库服务来提供远程数据库存储服务 数据库准备特别注意， ...

当要在代码中连接数据库时，往往需要登录用户的信息，而实际使用时登录用户常常变化，硬编码到代码中，改起来十分麻烦。所以使用Json技术将我们封装好的用户管理类序列化并储存到文件中，既能够持久化，还实现了软编码，使用户仅需方便地修改文件内容就能修改用户信息了。 用户配置类设计第三方库这里用到了两个第三方库 -ljsoncpp Json的第三方库 -lmysqlcppconn 数据库的第三方库 编译指令如下 1g++ -o $@ $^ -std=c++11 -ljsoncpp -lmysqlcppconn 代码实现作为MySQL用户配置，至少要支持储存如下信息 用户名 密码 数据库 登录ip 登录端口号 然后核心功能如下 成员变量的访问和设置 将配置写入文件 从文件读入配置 根据如上要求，我们设计的核心代码如下 DBUserConfig.hpp 12345678910111213141516171819202122232425262728293031#pragma once#include <jsoncpp/json/json.h>#include <s ...

解决异步日志器黏包问题由于原本的设计是一股脑直接把日志信息送进了缓冲区，导致输出的时候会产生黏包问题。但是为什么一开始没在意呢？因为标准输出和文件输出都不在意黏包问题，同时输出多条日志是没问题的。 但是！一旦要开始插入数据库，问题就很严重了。日志信息必须一行一行储存。原本的黏包问题会导致日志信息的解析不可解，所以我们需要修改原本的代码使其能够解决黏包问题 分隔符用特定的分隔符标记一次日志的头尾是最容易想到的解决方案。 然而日志信息是字符串,任何字符都有可能出现,导致找不到特定的分隔符可以安全地分隔日志信息 分隔符只适用于待封装信息的字符在限定范围内时使用。 封装报头假如我们能获得一段日志的长度就好了。 这样的愿望可以封装报头实现。在获取一长段数据时，我们规定最前面的是报头，包含第一段报文的信息(在这个项目里只简单的包括长度信息)。这样我们就能先读取信息再读取报文了。 那么怎么标定报头的范围呢？ 约定使用定长报头 约定使用分隔符 定长报头很好理解，而这里又能用分隔符了是因为报头在一段信息的最前面，最先遇到的特殊字符必定是作为分隔符存在的 这里因为没太多信息需要封装进报头，所以我们采 ...

为什么有用户管理类比Linux中只有root用户过于危险，因为root能随意地增删查改计算机上的任意文件 MySQL只有root用户登录也是十分危险的，因为root有增删查改所有数据库和表的权限，数据安全得不到保障，所以MySQL有自己的用户管理系统 用户管理的使用用户信息显然用户信息是需要组织和管理的，所以按照先描述，再组织的原则，我们来思考一下用户信息在逻辑上是什么样的管理思路 描述用户只需略微思考一下在MySQL中描述一个对象怎么样最方便准确，很明显，就是它自带的表结构。 实际上也确实是这样，MySQL用了一个在mysql数据库中的user表用来描述所有的用户 client1234567891011121314151617181920212223242526272829mysql> use mysqlDatabase changedmysql> select host,user,authentication_string from user;+-----------+------------------+-------------------------------- ...

《设计模式的C++实现》为作者对系列博客的又一次尝试：在开发过C++基于多设计模式下的同步&异步⽇志系统🔗后，作者接触到了《设计模式》这本书，颇有感触，于是决定写博客来记录读后的灵感，然而随着博客内容的不断丰富，单篇的博客已经承载不下如此多样的内容，各种各样的设计模式便是一个典例，所以我决定将设计模式相关的博客拆成一个系列博客 目录:TODO 知识基础本系列博客着重于经典设计模式的介绍和运用C++类和对象技术将其实现，所以要求读者已经能够熟练掌握C++类和对象技术。并且当我们提及抽象类，多态,或者继承，虚函数的声明与实现等概念时，你应当已经对这些概念了然于心，而不是一知半解，还要查资料复习 设计模式从何而来设计模式描述了在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案。设计模式捕获了随时间进化与发展的问题的求解方法，因此它们往往并不是人们从一开始就采用的设计方案，它们反映了不为人知的重新设计和重新编码的成果,而这些都来自软件开发者为了设计出灵活可复用的软件而长时间进行的艰苦努力。设计模式所做的事，就是捕获这些解决方案，并用简洁易用的方式表达出来。 学习目标设 ...

这是系列博客中的第二篇,导航如下 初识计算机网络🔗 初识Linux套接字(socket)和TCP/UDP协议🔗 👈您在这里 在Linux环境中，套接字（Socket）是一种用于进程间通信（IPC）的机制，但这里的进程，包括了同一网络下其它主机的进程，所以它被广泛应用于网络编程。它允许不同计算机上的进程或同一计算机上的不同进程之间进行数据交换。 由于此时我们的网络编程基础较少，所以本文的内容更偏向于实践,而不是原理。希望能在动手实践中加深对网络编程的熟悉程度，减少陌生感 在本文中，我们将： 知识铺垫:认识IP地址, 端口号, 网络字节序等网络编程中的基本概念（简略） socket API学习 实现一个简单的UPD客户端/服务器 实现一个简单的TCP客户端/服务器（服务器包括单连接版本，多进程版本，多线程版本） 知识铺垫理解源IP地址和目的IP地址在数据包的头部中，包含两个IP地址，分别叫做源IP地址和目的IP地址 为什么要有两个IP地址？因为一般通过网络建立的通信都是双向的,而且一方接收请求后，一般还要把响应发送回去，所以含有两个IP地址才 ...

代理模式 模式名称: 代理模式-Proxy类型: 结构型问题-使用场景: 在执行类和用户间再增加一个中间人，执行类的交互对于用户来说过于复杂，执行类的接口对参数检查较严格等解决方案： 可以封装一个类，为用户提供更简洁的接口，而与执行类的交互在其内部实现；或者封装一个头文件，在里面封装全局函数和宏函数等效果： 增加代码复杂性，封装层数更高，更加抽象。具体实现方式十分多样，增加了代码编写者的工作，但减少了用户的使用难度，也能一定程度上提高安全性 代理模式指代理控制对其他对象的访问， 也就是代理对象控制对原对象的引⽤。在某些情况下，⼀个对象不适合或者不能直接被引⽤访问，⽽代理对象可以在客⼾端和⽬标对象之间起到中介的作⽤。代理模式的结构包括⼀个是真正的你要访问的对象(⽬标类)、⼀个是代理对象。⽬标对象与代理对象实现同⼀个接⼝，先访问代理类再通过代理类访问⽬标对象 按照编译时和运行时的行为，代理模式分为静态代理、动态代理： 静态代理指的是，在编译时就已经确定好了代理类和被代理类的关系。也就是说，在编译时就已经确定了代理类要代理的是哪个被代理类。 动态代理指的是，在运⾏时才动态⽣成代理类，并将 ...

模式名称: 工厂模式-Factory类型: 创建型问题-使用场景: 当创建不同对象的过程过于复杂，或者需要隐藏/封装创建对象的具体过程，或需要创建同一家族的产品（对象）时解决方案：将创建对象的过程封装到工厂类内，并提供设置创建不同对象的接口效果： 简化了用户操作，使创建对象，创建多个不同的对象更为简单易用，提高了代码的封装性。但是代码复杂性大大提高，类封装的层次更多了，可扩展性会有所欠缺。 模式名称: 建造者模式-Builder类型: 创建型问题-使用场景: 当创建不同对象的过程过于复杂，或者需要隐藏/封装创建对象的具体过程，或需要创建同一家族的产品（对象）时解决方案：将创建对象的过程封装到Builder内，并提供设置创建不同对象的接口，以及提供不同的Builder派生类,最后提供一个指挥者类统一指挥对象的创建效果： 可扩展性强的同时，简化了用户操作，使创建对象，创建多个不同的对象更为简单易用，提高了代码的封装性。但是代码复杂性大大提高，类封装的层次更多了。 ⼯⼚模式是⼀种创建型设计模式， 它提供了⼀种创建对象的最佳⽅式。在⼯⼚模式中，我们创建对象时不会对上 ...