2018年01月_痞子锐

转载 fastdfs配置

http://bbs.chinaunix.net/thread-1941456-1-1.html昨天开始对学习FastDFS, 通过和版主的聊天对它进行了些了解,坚持交流进步的目的,现在对配置文件进行中文理解性的转译,小弟不才,错误的地方希望版主和各为达人指出,提出的问题望各位解答(贴子是在晚上吃饭前赶出来的,写的很粗槽,以后可以帮大家整理,写成标准的说明什么的首先是 tra

2018-01-29 08:19:53 231

转载 FastDFS 双tracker负载均衡及多组存储配置

应用场景: 三台服务器分别做三组存储，并且需要两台tracker地址做主备关系，当一台down机后需要另外一台可以提供正常的访问连接#注:此处不考虑存储数据安全性，如果需要保障数据不丢失，可以分别每台存储配置两组group(相同group之间数据会自动备份) ，三台服务器group分别为: 第一台服务器:group1 group2 第二台服务器:gro

2018-01-25 13:34:55 1865

转载 nginx+keepalived实现双机热备高可用性

搭建准备：机器两台 ip分别为192.168.100.128 192.168.100.129（可以用虚拟机测试，虚拟机网络模式为NET模式，且为静态ip）另外需要准备一个虚拟ip对外提供服务，即通过该ip访问web程序。（keepalive会将虚拟ip绑定到两台机器上）keepalived的核心原理是vrrp协议，英文好可以查看最新协议RFC3768。1.nginx安装

2018-01-20 10:41:55 266

转载 nginx+keepalived实现双机双主高可用性

1.前言上篇文章我们配置的双机热备，意思是说两台机器一台处于运行中，另一台永久处于备份。这样的话资源浪费严重，适用于国企,政府类系统。今天我们所讲的是双机双主热备，意味着两台机器同时处于工作状态，两台主机又同时为备份状态。2.准备：两台主机192.168.100.128/24 192.168.100.129/24两个单独的ip 192.168.100.133/24

2018-01-20 10:41:42 214

转载 MySQL数据库高并发优化配置

在Apache, PHP, mysql的体系架构中，MySQL对于性能的影响最大，也是关键的核心部分。对于Discuz!论坛程序也是如此，MySQL的设置是否合理优化，直接影响到论坛的速度和承载量！同时，MySQL也是优化难度最大的一个部分，不但需要理解一些MySQL专业知识，同时还需要长时间的观察统计并且根据经验进行判断，然后设置合理的参数。下面我们了解一下MySQL

2018-01-20 10:41:26 501

转载一分钟了解负载均衡的一切

什么是负载均衡负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。常见的负载均衡方案常见互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到，每一个下游都有多个上游调用，只需要做到，每一个上游都均匀访问每一个下游，就能实现“将请求/数据【均匀】分摊

2018-01-19 14:48:20 210

零、需求缘起第一篇文章“一分钟了解负载均衡”和大家share了互联网架构中反向代理层、站点层、服务层、数据层的常用负载均衡方法。第二篇文章“lvs为何不能完全代替DNS轮询”和大家share了互联网接入层负载均衡需要解决的问题及架构演进。在这两篇文章中，都强调了“负载均衡是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】”。然而，后端的service有可能部署在硬件条件

2018-01-19 14:48:16 235

转载 lvs为何不能完全替代DNS轮询

上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注，评论中大家争论的比较多的一个技术点是接入层负载均衡技术，部分同学持这样的观点：1）nginx前端加入lvs和keepalived可以替代“DNS轮询”2）F5能搞定接入层高可用、扩展性、负载均衡，可以替代“DNS轮询”“DNS轮询”究竟是不是过时的技术，是不是可以被其他方案替代，接入层架构技术演进，是本文将要细致讨论的内容。一、问题域n

2018-01-19 14:48:09 170

转载究竟啥才是互联网架构“高并发”

一、什么是高并发高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200

2018-01-19 14:48:02 223

转载究竟啥才是互联网架构“高可用”

一、什么是高可用高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。百度

2018-01-19 14:47:56 209

转载 100亿数据1万属性数据架构设计

一、背景描述及业务介绍问：什么是数据库扩展的version + ext方案？使用ext来承载不同业务需求的个性化属性，使用version来标识ext里各个字段的含义。例如上述user表：verion=0表示ext里是passwd/nickversion=1表示ext里是passwd/nick/age/sex 优点？（1）可以随时动态扩展属性，扩展性好（2）新旧两种数据可以同时存在，兼容性好不足？（

2018-01-19 14:47:46 203

转载互联网架构为什么要做服务化？

一、互联网高可用架构，为什么要服务化？【服务化之前高可用架构】在服务化之前，互联网的高可用架构大致是这样一个架构：（1）用户端是浏览器browser，APP客户端（2）后端入口是高可用的nginx集群，用于做反向代理（3）中间核心是高可用的web-server集群，研发工程师主要编码工作就是在这一层（4）后端存储是高可用的db集群，数据存储在这一层更典型的，web-server层是通过DAO/O

2018-01-19 14:47:33 147

转载微服务架构多“微”才合适？

前情提要：互联网架构为什么要做服务化？一、互联网架构为什么要进行服务化-总结上一篇和大伙交流了一下，随着数据量、并发量、业务复杂度的增长，互联网架构会出现以下问题：（1）代码到处拷贝（2）底层复杂性扩散（3）基础库（so/jar/dll）耦合（4）SQL质量得不到保障，业务相互影响（5）数据库耦合“服务化”是一个很好的解决上述痛点的方案。不少评论也提出了不少有建设性的观点，汇总出来分享给大伙：@

2018-01-19 14:47:27 267

转载为什么说要搞定微服务架构，先搞定RPC框架？

今天开始聊一些微服务的实践，第一块，RPC框架的原理及实践，为什么说要搞定微服务架构，先搞定RPC框架呢？一、需求缘起服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦，如下图：服务A是欧洲团队提供服务，欧洲团队的技术背景是Java，可以用Java实现服务；服务B是美洲团队提供服务，可以用C++实现服务；服务C是中国团队提供服务，可以用Go实现服务；服务的上游

2018-01-19 14:47:21 247

转载 nginx------nginx配置详解

2018-01-19 14:31:37 246

转载 tomcat------tomcat下的日志配置详细说明

1 #可配置项(5类日志)：catalina、localhost、manager、admin、host-manager 2 handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3 3manager.org.apache.juli.FileHandler, 4host-

2018-01-16 17:07:10 408

转载 lcentos7------作为web服务器优化

centos7作为web服务器优化1、关闭firewalld：systemctl stop firewalld.service #停止firewall systemctl disable firewalld.service #禁止firewall开机启动2、安装iptables防火墙yum install iptables-services #安装 iptables -nvL #查看信息3

2018-01-16 16:09:44 1357

转载 RPC-client异步收发核心细节？

第一章聊了【“为什么要进行服务化，服务化究竟解决什么问题”】第二章聊了【“微服务的服务粒度选型”】第三章聊了【“为什么说要搞定微服务架构，先搞定RPC框架？”】上一章聊了【“微服务架构之RPC-client序列化细节”】通过上篇文章的介绍，知道了要实施微服务，首先要搞定RPC框架，RPC框架分为客户端部分与服务端部分。RPC-client的部

2018-01-16 11:19:09 344

转载微信为什么不丢消息？

一、报文类型im的客户端与服务器通过发送报文（也就是网络包）来完成消息的传递，报文分为三种请求报文（request，后简称为为R）应答报文（acknowledge，后简称为A）通知报文（notify，后简称为N），这三种报文的解释如下：R：客户端主动发送给服务器的报文A：服务器被动应答客户端的报文，一个A对应一个RN：服务器主动发送给客户端的报文

2018-01-16 11:18:51 196

转载 JVM内存参数详解以及配置调优

基本概念：PermGen space：全称是Permanent Generation space。就是说是永久保存的区域,用于存放Class和Meta信息，Class在被Load的时候被放入该区域Heap space：存放Instance。GC(Garbage Collection)应该不会对PermGen space进行清理所以如果你的APP会LOAD很多CLASS的话，就很可能出现

2018-01-16 08:46:59 265

转载 JVM(6)--JVM各种参数及调优

GC有两种类型：Scavenge GC 和Full GC1、Scavenge GC一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，堆的Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor的两个区中。 2、Full GC 对整个堆进行整理，包括Young、Tenured和Perm。Full GC 比Scave

2018-01-16 08:25:11 229

转载配置Tomcat apr运行模式

tomcat中一共有三种运行模式，分别是:bio,nio,apr　　bio是阻塞式IO操作，使用的是传统的java i/o处理方式，对于每一个请求都要创建一个线程来进行处理，所以开销较大不适合处理高并发的场景　　nio是基于java中非阻塞IO操作的API实现，比传统的i/o处理方式有更高的并发运行性能，启动时可以看到：　　　　apr是从操作系统级别解决异步IO问题，大幅度提高服务器的并发处理性能

2018-01-15 17:36:29 608

转载 Apache Tomcat 8.5 安全配置与高并发优化

https://www.renwole.com/archives/357通常我们在生产环境中，Tomcat的默认配置显然不能满足我们的产品需求，所以很多时候都需要对Tomcat的配置进行调优，以下综合我自己的经验来配置 Tomcat 安全与优化情况，如果你有更好的方案，请留言，我会参考并加纳进去。关于JAVA JDK JRE的安装配置，请阅读《Linux JAVA JDK JRE 环境变量安装与配

2018-01-15 16:18:56 1002

转载单点登陆

转载：http://blog.csdn.net/xqhys/article/details/63920161?locationNum=3&fps=1一、什么是单点登录SSO（Single Sign-On）　　SSO是一种统一认证和授权机制，指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新

2018-01-13 13:53:13 214

转载微信为啥不丢“离线消息”？

需求缘起当发送方用户A发送消息给接收方用户B时，如果用户B在线，之前的文章《微信为啥不丢“在线消息”？》聊过，可以通过应用层的确认，发送方的超时重传，接收方的去重保证业务层面消息的不丢不重。那如果接收方用户B不在线，系统是如何保证消息的可达性的呢？这是本文要讨论的问题。问题：接收方不在线时，消息发送的流程是怎么样的？回答：如上图所述，（1）

2018-01-13 13:48:50 470

转载微信多点登录与QQ消息漫游架构随想

【需求缘起】之前的一些文章简单介绍了《“单人消息”》《“离线消息”》《“群消息”》《“用户状态”》的一些相关技术（点击上面的link直接阅读），今天来聊一聊“多点登陆”与“消息漫游”。提问：什么是多点登录？回答：以微信为例，可以PC端，phone端同时登录，同时收发消息。需要注意的是，一个端只能登录一个实例，例如同一个QQ号，在pc1上登录，再到

2018-01-13 13:48:26 397

转载群消息这么复杂，怎么能做到不丢不重？

【需求缘起】之前的文章更多的聊了单对单的消息投递：《微信为什么不丢消息？》《http如何像tcp一样实时的收消息？》群聊是多人社交的基本诉求，不管是QQ群，还是微信群，一个群友在群内发了一条消息：（1）在线的群友能第一时间收到消息（2）离线的群友能在登陆后收到消息由于“消息风暴扩散系数”的存在（概念详见《QQ状态同步究竟是推还

2018-01-13 13:48:05 245

转载微服务架构之RPC-client序列化细节

第一章聊了【“为什么要进行服务化，服务化究竟解决什么问题”】第二章聊了【“微服务的服务粒度选型”】上一篇聊了【“为什么说要搞定微服务架构，先搞定RPC框架？”】通过上篇文章的介绍，知道了要实施微服务，首先要搞定RPC框架，RPC框架的职责要向【调用方】和【服务提供方】屏蔽各种复杂性：（1）让调用方感觉就像调用本地函数一样（2）让服务提供方感觉就像

2018-01-13 13:47:35 494

转载单点系统架构的可用性与性能优化

一、需求缘起明明架构要求高可用，为何系统中还会存在单点？回答：单点master的设计，会大大简化系统设计，何况有时候避免不了单点在哪些场景中会存在单点？先来看一下一个典型互联网高可用架构。典型互联网高可用架构：（1）客户端层，这一层是浏览器或者APP，第一步先访问DNS-server，由域名拿到nginx的外网IP（2）负载均衡层，ng

2018-01-13 13:47:20 181

转载 58到家通用实时消息平台架构细节（Qcon2016）

一、解决什么问题 + 难点解决什么业务问题（1）端到云的实时上报需求：58速运司机端GPS实时上报（2）云到端的实时推送需求：58速运司机订单实时推送（3）端到端的聊天消息需求：用户、商户、客服之间的聊天沟通难点：（1）APP无线环境下消息可达性（2）通用性，平台实现尽量与业务解耦二、传统解决方案与潜在不足【端

2018-01-13 13:47:00 247

转载微信为啥这么省流量？

一、报文类型im的客户端与服务器通过发送报文（也就是网络包）来完成消息的传递，报文分为三种请求报文（request，后简称为为R）应答报文（acknowledge，后简称为A）通知报文（notify，后简称为N），这三种报文的解释如下：R：客户端主动发送给服务器的报文A：服务器被动应答客户端的报文，一个A对应一个RN：服务器主动发送给客户端的报文

2018-01-13 13:46:40 246

转载应用层/安全层/传输层如何进行协议选型？

架构师之路系统设计，协议先行。大部分技术人没有接触协议的设计细节，更多的是使用已有协议进行应用层的编码，例如：（1）使用http作为载体，设计get/post/cookie参数（2）使用dubbo框架，而不用去深究内部的二进制包头包体，以及序列号反序列化的细节无论如何，了解协议设计的原则，对深入理解系统通信非常有帮助。今天就以即时

2018-01-13 13:46:03 448

原创 linux常用命令

Linux简介及Ubuntu安装Linux，免费开源，多用户多任务系统。基于Linux有多个版本的衍生。RedHat、Ubuntu、Debian安装VMware或VirtualBox虚拟机。具体安装步骤，找百度。再安装Ubuntu。具体安装步骤，找百度。安装完后，可以看到Linux系统的目录结构，见链接http://www.cnblogs.com/laov/p/3409875.ht...

2018-01-13 13:45:25 146

转载 http如何像tcp一样实时的收消息？

http如何像tcp一样实时的收消息？一、webim如何实现消息推送webim通常有三种方式实现推送通道：1）WebSocket2）FlashSocket3）http轮询其中1）和2）是用Tcp长连接实现的，其消息的实时性可以通过tcp保证。方案3）才算是webim实现消息推送的“正统”方案，用http短连接轮询的方式实现“伪长连接”，既然是轮询，有朋友

2018-01-08 09:50:07 185

转载数据库软件架构设计些什么

缘起：受@萧田国萧总邀请，上周五晚上在“高效运维1号群”内分享了《58同城数据库软件架构设计与实践》（这个topic今年在数据库大会上分享过），应组织方要求，发出纪要。一、基本概念二、数据库架构设计思路（1）可用性（2）读性能（3）一致性（4）扩展性一、基本概念概念一“单库”

2018-01-08 09:49:53 232

转载缓存架构设计细节二三事

本文主要讨论这么几个问题：（1）“缓存与数据库”需求缘起（2）“淘汰缓存”还是“更新缓存”（3）缓存和数据库的操作时序（4）缓存和数据库架构简析一、需求缘起场景介绍缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。例如对于用户的余额信息表account(uid, money)，业务上

2018-01-08 09:27:48 201

转载细聊冗余表数据一致性（架构师之路）

本文主要讨论四个问题：（1）为什么会有冗余表的需求（2）如何实现冗余表（3）正反冗余表谁先执行（4）冗余表如何保证数据的一致性一、需求缘起互联网很多业务场景的数据量很大，此时数据库架构要进行水平切分，水平切分会有一个patition key，通过patition key的查询能够直接定位到库，但是非patition key上的查询可能就

2018-01-08 09:19:11 229

转载缓存与数据库一致性保证

本文主要讨论这么几个问题：（1）啥时候数据库和缓存中的数据会不一致（2）不一致优化思路（3）如何保证数据库与缓存的一致性一、需求缘起上一篇《缓存架构设计细节二三事》（点击查看）引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库”这个点是大家讨论的最多的。上篇文章得出这个结论的依据是，由于操作缓存与操作

2018-01-08 09:18:55 243

转载 DB主从一致性架构优化4种方法

需求缘起大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用“一主多从，读写分离，冗余多个读库”的数据库架构来提升数据库的读性能。这种架构的一个潜在缺点是，业务方有可能读取到并不是最新的旧数据：（1）系统先对DB-master进行了一个写操作，写主库（2）很短的时间内并发进行了一个读操作，读从库，此时主从同步没有完成

2018-01-08 09:18:25 131

空空如也

空空如也