<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[gauss的专栏]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/mathlmx</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; mathlmx]]></copyright><item><title><![CDATA[直播服务器简单实现 http_flv和hls 内网直播桌面]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/54375395</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/54375395</guid><author>mathlmx</author><pubDate>Thu, 12 Jan 2017 10:09:05 +0800</pubDate><description><![CDATA[直播都不陌生了，如今主流的协议分析的对比图，个人见解。




协议


httpflv


rtmp


hls


dash




传输层


http流


tcp流


http


http




视频格式


flv


flv tag


Ts文件


Mp4 3gp webm]]></description><category></category></item><item><title><![CDATA[Codis集群的搭建与使用]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/52815068</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/52815068</guid><author>mathlmx</author><pubDate>Fri, 14 Oct 2016 13:02:41 +0800</pubDate><description><![CDATA[一、简介  

Codis是一个分布式的Redis解决方案，对于上层的应用来说，连接Codis Proxy和连接原生的Redis Server没有明显的区别（不支持的命令列表），上层应用可以像使用单机的Redis一样使用，Codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的一切事情，对于前面客户端来说是透明的，可以简单的认为后边连接是一个内存无限大的Redis服务。

Cod]]></description><category></category></item><item><title><![CDATA[用shell脚本监控进程是否存在 不存在则启动的实例]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/52402855</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/52402855</guid><author>mathlmx</author><pubDate>Thu, 01 Sep 2016 19:44:45 +0800</pubDate><description><![CDATA[用shell脚本监控进程是否存在 不存在则启动的实例，先上代码干货：

#!/bin/sh
ps -fe|grep processString |grep -v grep
if [ $? -ne 0 ]
then
echo "start process....."
else
echo "runing....."
fi
#####
processString 表示进程特征字符串]]></description><category></category></item><item><title><![CDATA[MySQL性能优化总结]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/52369613</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/52369613</guid><author>mathlmx</author><pubDate>Tue, 30 Aug 2016 15:21:31 +0800</pubDate><description><![CDATA[一、MySQL的主要适用场景

1、Web网站系统

2、日志记录系统

3、数据仓库系统

4、嵌入式系统

二、MySQL架构图：



 

三、MySQL存储引擎概述

1）MyISAM存储引擎

MyISAM存储引擎的表在数据库中，每一个表都被存放为三个以表名命名的物理文件。首先肯定会有任何存储引擎都不可缺少的存放表结构定义信息的.frm文件，另外]]></description><category></category></item><item><title><![CDATA[Nginx负载均衡配置实例详解]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/52332635</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/52332635</guid><author>mathlmx</author><pubDate>Fri, 26 Aug 2016 23:41:18 +0800</pubDate><description><![CDATA[负载均衡是我们大流量网站要做的一个东西，下面我来给大家介绍在NGINX服务器上进行负载均衡配置方法，希望对有需要的同学有所帮助哦。负载均衡先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。

直接上成功的参数，实现了本机均衡并本机的NGIN]]></description><category></category></item><item><title><![CDATA[微服务实战（六）：选择微服务部署策略]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51914033</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51914033</guid><author>mathlmx</author><pubDate>Fri, 15 Jul 2016 00:10:01 +0800</pubDate><description><![CDATA[【编者的话】这篇博客是用微服务建应用的第六篇，第一篇介绍了微服务架构模板，并且讨论了使用微服务的优缺点。随后的文章讨论了微服务不同方面：使用API网关，进程间通讯，服务发现和事件驱动数据管理。这篇文章，我们将讨论部署微服务的策略。

本系列文章：

微服务实战（一）：微服务架构的优势与不足微服务实战（二）：使用API Gateway微服务实战（三）：深入微服务架构的进程间通信微服务实战（四]]></description><category></category></item><item><title><![CDATA[微服务实践（五）：微服务的事件驱动数据管理]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51913951</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51913951</guid><author>mathlmx</author><pubDate>Thu, 14 Jul 2016 23:52:50 +0800</pubDate><description><![CDATA[【编者的话】本文是使用微服务创建应用系列的第五篇文章。第一篇文章介绍了微服务架构模式，并且讨论了使用微服务的优缺点；第二和第三篇描述了微服务架构模块间通讯的不同方面；第四篇研究了服务发现中的问题。本篇中，我们从另外一个角度研究一下微服务架构带来的分布式数据管理问题。
1.1 微服务和分布式数据管理问题
单体式应用一般都会有一个关系型数据库，由此带来的好处是应用可以使用 ACID transac]]></description><category></category></item><item><title><![CDATA[微服务实战（四）：服务发现的可行方案以及实践案例]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51913945</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51913945</guid><author>mathlmx</author><pubDate>Thu, 14 Jul 2016 23:51:39 +0800</pubDate><description><![CDATA[这是关于使用微服务架构创建应用系列的第四篇文章。第一篇介绍了微服务架构的模式，讨论了使用微服务架构的优缺点。第二和第三篇描述了微服务架构内部的通讯机制。这篇文章中，我们将会探讨服务发现相关问题。
为什么要使用服务发现?
设想一下，我们正在写代码使用了提供REST API或者Thrift API的服务，为了完成一次服务请求，代码需要知道服务实例的网络位置（IP地址和端口）。传统应用都运行在物理硬]]></description><category></category></item><item><title><![CDATA[微服务实战（三）：深入微服务架构的进程间通信]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51913939</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51913939</guid><author>mathlmx</author><pubDate>Thu, 14 Jul 2016 23:50:26 +0800</pubDate><description><![CDATA[【编者的话】这是采用微服务架构创建自己应用系列第三篇文章。第一篇介绍了微服务架构模式，和单体式模式进行了比较，并且讨论了使用微服务架构的优缺点。第二篇描述了采用微服务架构应用客户端之间如何采用API Gateway方式进行通信。在这篇文章中，我们将讨论系统服务之间如何通信。
简介
在单体式应用中，各个模块之间的调用是通过编程语言级别的方法或者函数来实现的。但是一个基于微服务的分布式应用是运行在]]></description><category></category></item><item><title><![CDATA[微服务实战（二）：使用API Gateway]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51913931</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51913931</guid><author>mathlmx</author><pubDate>Thu, 14 Jul 2016 23:49:03 +0800</pubDate><description><![CDATA[【编者的话】本系列的第一篇介绍了微服务架构模式。它讨论了采用微服务的优点和缺点，除了一些复杂的微服务，这种模式还是复杂应用的理想选择。

当你决定将应用作为一组微服务时，需要决定应用客户端如何与微服务交互。在单体式程序中，通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中，每一个微服务暴露一组细粒度的服务提供点。在本篇文章中，我们来看它如何影响客户端到服务端通信，同时提出一种API G]]></description><category></category></item><item><title><![CDATA[微服务实战（一）：微服务架构的优势与不足]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51913921</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51913921</guid><author>mathlmx</author><pubDate>Thu, 14 Jul 2016 23:47:52 +0800</pubDate><description><![CDATA[【编者的话】本文来自Nginx官方博客，是微服务系列文章的第一篇，主要探讨了传统的单体式应用的不足，以及微服务架构的优势与挑战。正如作者所说，微服务架构更适合用于构建复杂的应用，尽管它也有自己的不足。

这篇文章作者是Chris Richardson，他是早期基于Java的Amazonite EC2 PaaS平台CloudFoundry.com的创始人。现在他为企业提供如何开发和部署应用的咨询]]></description><category></category></item><item><title><![CDATA[LVS 工作模式以及工作原理]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51043051</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51043051</guid><author>mathlmx</author><pubDate>Sat, 02 Apr 2016 10:59:36 +0800</pubDate><description><![CDATA[LVS 简介
         LVS 是 Linux  Virtual Server ，Linux 虚拟服务器；是一个虚拟的服务器集群【多台机器 LB IP】。LVS 集群分为三层结构:

负载调度器(load balancer)：它是整个LVS 集群对外的前端机器，负责将client请求发送到一组服务器[多台LB IP]上执行，而client端认为是返回来一个同一个IP【通常把这个IP ]]></description><category></category></item><item><title><![CDATA[LB 负载均衡的层次结构]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/51042705</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/51042705</guid><author>mathlmx</author><pubDate>Sat, 02 Apr 2016 09:45:29 +0800</pubDate><description><![CDATA[作为后端应用的开发者，我们经常开发、调试、测试完我们的应用并发布到生产环境，用户就可以直接访问到我们的应用了。但对于互联网应用，在你的应用和用户之间还隔着一层低调的或厚或薄的负载均衡层软件，它们不显山不露水默默的发挥着重要的作用，以至于我们经常忽略了它们的存在。因为负载均衡层通常不在一般开发人员的问题域内，而且它们一般都是现成且成熟的解决方案，以至于我们习惯性的忽略和认为乏善可陈。其实不然，本文就]]></description><category></category></item><item><title><![CDATA[WebSocket 实战]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/50709847</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/50709847</guid><author>mathlmx</author><pubDate>Sun, 21 Feb 2016 22:19:29 +0800</pubDate><description><![CDATA[WebSocket 前世今生
众所周知，Web 应用的交互过程通常是客户端通过浏览器发出一个请求，服务器端接收请求后进行处理并返回结果给客户端，客户端浏览器将信息呈现，这种机制对于信息变化不是特别频繁的应用尚可，但对于实时要求高、海量并发的应用来说显得捉襟见肘，尤其在当前业界移动互联网蓬勃发展的趋势下，高并发与用户实时响应是 Web 应用经常面临的问题，比如金融证券的实时信息，Web 导航应用中]]></description><category></category></item><item><title><![CDATA[几种经典的网络服务器架构模型的分析与比较]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/50359848</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/50359848</guid><author>mathlmx</author><pubDate>Sat, 19 Dec 2015 21:42:26 +0800</pubDate><description><![CDATA[前言


事件驱动为广大的程序员所熟悉，其最为人津津乐道的是在图形化界面编程中的应用；事实上，在网络编程中事件驱动也被广泛使用，并大规模部署在高连接数高吞吐量的服务器程序中，如 http 服务器程序、ftp 服务器程序等。相比于传统的网络编程方式，事件驱动能够极大的降低资源占用，增大服务接待能力，并提高网络传输效率。


关于本文提及的服务器模型，搜索网络可以查阅到很多的实现代码，所以]]></description><category></category></item><item><title><![CDATA[thrift之TTransport层的堵塞的套接字I/O传输类TSocket]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/49624437</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/49624437</guid><author>mathlmx</author><pubDate>Tue, 03 Nov 2015 23:31:21 +0800</pubDate><description><![CDATA[本节将介绍第一个实现具体传输功能的类TSocket，这个类是基于TCP socket实现TTransport的接口。下面具体介绍这个类的相关函数功能实现。
　　1.构造函数
　　分析一个类的功能首先看它的定义和构造函数实现，先看看它的定义：


[cpp] 
view plaincopyprint?


class TSocket : public TVirtualTranspo]]></description><category></category></item><item><title><![CDATA[Facebook之Thrift简介]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/49624285</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/49624285</guid><author>mathlmx</author><pubDate>Tue, 03 Nov 2015 23:22:26 +0800</pubDate><description><![CDATA[以下内容是从网上各处简单整理而来，因为前段时间自己一直在研究Thrift，把研究的一点资料分享给需要的同行中人！
第一节 RPC技术及实现简介
首先思考一下分布式系统中的 RPC (Remote Procedure Call) 问题，一个完整的 RPC 模块需要可以分为三个层次
· 服务层（service）：RPC 接口定义与实现
· 协议层（protocol）：RPC 报文格式和数据编码]]></description><category></category></item><item><title><![CDATA[nginx平台初探(五)]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/49556887</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/49556887</guid><author>mathlmx</author><pubDate>Sun, 01 Nov 2015 11:26:12 +0800</pubDate><description><![CDATA[其他模块 (40%)
Nginx的模块种类挺多的，除了HTTP模块，还有一些核心模块和mail系列模块。核心模块主要是做一些基础功能，比如Nginx的启动初始化，event处理机制，错误日志的初始化，ssl的初始化，正则处理初始化。
mail模块可以对imap，pop3，smtp等协议进行反向代理，这些模块本身不对邮件内容进行处理。

core模块 (40%)

Nginx的启动模块 ]]></description><category></category></item><item><title><![CDATA[nginx平台初探(四)]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/49556857</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/49556857</guid><author>mathlmx</author><pubDate>Sun, 01 Nov 2015 11:19:17 +0800</pubDate><description><![CDATA[upstream模块

upstream模块 (100%)
nginx模块一般被分成三大类：handler、filter和upstream。前面的章节中，读者已经了解了handler、filter。利用这两类模块，可以使nginx轻松完成任何单机工作。而本章介绍的upstream模块，将使nginx跨越单机的限制，完成网络数据的接收、处理和转发。
数据转发功能，为nginx提供了跨越单机的]]></description><category></category></item><item><title><![CDATA[nginx平台初探(三)]]></title><link>https://blog.youkuaiyun.com/mathlmx/article/details/49556839</link><guid>https://blog.youkuaiyun.com/mathlmx/article/details/49556839</guid><author>mathlmx</author><pubDate>Sun, 01 Nov 2015 11:17:26 +0800</pubDate><description><![CDATA[过滤模块 (90%)

过滤模块简介 (90%)

执行时间和内容 (90%)
过滤（filter）模块是过滤响应头和内容的模块，可以对回复的头和内容进行处理。它的处理时间在获取回复内容之后，向用户发送响应之前。它的处理过程分为两个阶段，过滤HTTP回复的头部和主体，在这两个阶段可以分别对头部和主体进行修改。
在代码中有类似的函数：

ngx_http_top_header_fil]]></description><category></category></item></channel></rss>