Elasticsearch史上最全最常用工具清单

2018-6-10 孤独求学人 架构

Elasticsearch史上最全最常用工具清单

1、题记
工欲善其事必先利其器，ELK Stack的学习和实战更是如此，特将工作中用到的“高效”工具分享给大家。

希望能借助“工具”提高开发、运维效率！

2、工具分类概览
2.1 基础类工具
1、Head插件

1）功能概述：

ES集群状态查看、索引数据查看、ES DSL实现（增、删、改、查操作）
比较实用的地方：json串的格式化



2）地址：http://mobz.github.io/elasticsearch-head/

2、Kibana工具

除了支持各种数据的可视化之外，最重要的是：支持Dev Tool进行RESTFUL API增删改查操作。
——比Postman工具和curl都方便很多。

阅读全文>>

标签: ansible Elasticsearch elk

评论(0) 浏览(2453)

数据库从0到0.1 ： OLTP VS OLAP VS HTAP

2018-5-27 孤独求学人 架构

OLTP是Online Transaction Processing的简称；OLAP是OnLine Analytical Processing的简称；HTAP是Hybrid Transactional/Analytical Processing的简称。Transaction是指形成一个逻辑单元，不可分割的一组读，写操作；Online一般指查询延迟在秒级或毫秒级，可以实现交互式查询。

OLTP的查询一般只会访问少量的记录，且大多时候都会利用索引。在线的面向终端用户直接使用的Web应用：金融，博客，评论，电商等系统的查询都是OLTP查询，比如最常见的基于主键的CRUD操作。

OLAP的查询一般需要Scan大量数据，大多时候只访问部分列，聚合的需求（Sum，Count，Max，Min等）会多于明细的需求（查询原始的明细数据）。 OLAP的典型查询一般像：现在各种应用在年末会发布的大数据分析和统计应用，比如2017豆瓣读书报告，2017豆瓣读书榜单，网易云音乐2017听歌报告； OLAP在企业中的一个重要应用就是BI分析，比如2017年最畅销的手机品牌Top5;哪类人群最喜欢小米或华为手机等等。

《Designing-Data-Intensive-Applications》一书指出的OLTP和OLAP的主要区别如下：

在CMU-CS 15-415的课程中对OLAP和OLTP这样介绍：

阅读全文>>

标签: oltp olap HTAP

评论(0) 浏览(1982)

同为分布式缓存，为何Redis更胜一筹？

2018-3-26 孤独求学人 架构

如今，市面上的缓存解决方案已经逐步成熟了，今天我将选取其中一些代表性的方案包括Redis、Memcached和Tair进行对比，帮助大家在生产实践中更好地进行技术选型。

一、常用的分布式缓存的对比

常用的分布式缓存包括Redis、Memcached和阿里巴巴的Tair（见下表），因为Redis提供的数据结构比较丰富且简单易用，所以Redis的使用广泛。

下面我们从9个大方面来对比最常用的Redis和Memcached。

阅读全文>>

标签: redis memcache tari

评论(0) 浏览(1378)

常见 Web 安全攻防总结

2018-1-9 孤独求学人 架构

Web 安全的对于 Web 从业人员来说是一个非常重要的课题，所以在这里总结一下 Web 相关的安全攻防知识，希望以后不要再踩雷，也希望对看到这篇文章的同学有所帮助。今天这边文章主要的内容就是分析几种常见的攻击的类型以及防御的方法。

也许你对所有的安全问题都有一定的认识，但最主要的还是在编码设计的过程中时刻绷紧安全那根弦，需要反复推敲每个实现细节，安全无小事。
本文代码 Demo 都是基于 Node.js 讲解，其他服务端语言同样可以参考。

XSS

首先说下最常见的 XSS 漏洞，XSS (Cross Site Script)，跨站脚本攻击，因为缩写和 CSS (Cascading Style Sheets) 重叠，所以只能叫 XSS。

XSS 的原理是恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。XSS 的攻击方式千变万化，但还是可以大致细分为几种类型。

非持久型 XSS

非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，一般是通过给别人发送带有恶意脚本代码参数的 URL，当 URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。

阅读全文>>

标签: web xss flash csrf sql

评论(0) 浏览(9758)

维护了这么久的服务器，你真的认识 Web 缓存体系？

2017-9-8 孤独求学人 架构

1、认识Web缓存知识体系

1.1从HTTP请求说起

我们从一个Http的请求开始，先介绍下环境，左边是我们的用户端浏览器，右边是我们的Web服务器，当然Web服务器后面整体架构就不说了。

• 第一步，当用户浏览器发出一个请求，这个请求会经过网络到达Web服务器。这句话说明了当一个数据包从用户端发送到Web服务器端，这个时间是时网络延迟时间。
• 第二步，Web服务器处理请求，并响应数据。如果是动态请求我需要查缓存，查数据库，最终把请求返回给浏览器，这个时间是响应时间。
• 第三步，响应数据从Web服务器发送给用户端，这又是网络传输时间。
• 第四步，用户浏览器接收数据，本地计算和渲染。这个时间就是计算和渲染的时间，你的JS脚本不一样，渲染时间也是不一样的，但是这个时间是比较小的。

阅读全文>>

标签: http web cache

评论(0) 浏览(1420)

如何建设高可用系统

2017-5-26 孤独求学人 架构

面试的时候经常会问一个问题，如何建设高可用系统？大家可以一起探讨下。

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。以下是高可用系统的设计建议：

设计建议

• 减少单点 – 去单点首先要识别整个系统所有主链路的单点，如机房（同城异地双机房），应用服务器，DNS服务器，SFTP服务器，LBS，缓存服务器，数据库，消息服务器，代理服务器和专线等，如系统通过专线调用对方服务，需要考虑同时拉联通和电信的专线，联通或电信的专线还是有一定概率会出现问题的，但是同时出问题的概率会小非常多。优先使用软负载，使用硬负载兜底。
• 减少依赖 – 减少DNS依赖，减少远程服务依赖，DNS依赖可以尝试设置本地host，用工具给所有服务器推送最新的域名映射关系，通过本地缓存或近端服务减少RPC调用。
• 限制循环 – 避免无限死循环，导致CPU利用率百分百，可以设置for循环的最大循环次数，如最大循环1000次。

阅读全文>>

标签: High Availability 高可用系统

评论(0) 浏览(1320)

磁盘I/O那些事

2017-5-19 孤独求学人 架构

背景

计算机硬件性能在过去十年间的发展普遍遵循摩尔定律，通用计算机的CPU主频早已超过3GHz，内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长迅速，但是在读写性能上并无明显提升，同时SSD硬盘价格高昂，不能在短时间内完全替代传统硬盘。传统磁盘的I/O读写速度成为了计算机系统性能提高的瓶颈，制约了计算机整体性能的发展。

硬盘性能的制约因素是什么？如何根据磁盘I/O特性来进行系统设计？针对这些问题，本文将介绍硬盘的物理结构和性能指标，以及操作系统针对磁盘性能所做的优化，最后讨论下基于磁盘I/O特性设计的技巧。

硬盘的物理结构

硬盘内部主要部件为磁盘盘片、传动手臂、读写磁头和主轴马达。实际数据都是写在盘片上，读写主要是通过传动手臂上的读写磁头来完成。实际运行时，主轴让磁盘盘片转动，然后传动手臂可伸展让读取头在盘片上进行读写操作。磁盘物理结构如下图所示：

由于单一盘片容量有限，一般硬盘都有两张以上的盘片，每个盘片有两面，都可记录信息，所以一张盘片对应着两个磁头。盘片被分为许多扇形的区域，每个区域叫一个扇区，硬盘中每个扇区的大小固定为512字节。盘片表面上以盘片中心为圆心，不同半径的同心圆称为磁道，不同盘片相同半径的磁道所组成的圆柱称为柱面。磁道与柱面都是表示不同半径的圆，在许多场合，磁道和柱面可以互换使用。磁盘盘片垂直视角如下图所示：

阅读全文>>

标签: io.system

评论(0) 浏览(1306)

大型网站技术架构-入门梳理

2017-1-8 孤独求学人 架构

罗列了大型网站架构涉及到的概念，附上了简单说明

前言

• 本文是对《大型网站架构设计》(李智慧 著)一书的梳理，类似文字版的“思维导图”
• 全文主要围绕“性能，可用性，伸缩性，扩展性，安全”这五个要素
• 性能，可用性，伸缩性这几个要素基本都涉及到应用服务器，缓存服务器，存储服务器这几个方面

概述

• 三个纬度：演化、模式、要素
• 五个要素： 性能，可用性，伸缩性，扩展性，安全

演化历程

图例可参考 大型网站架构演化历程：

1. 初始阶段的网站架构：一台服务器，上面同时拥有应用程序，数据库，文件，等所有资源。例如 LAMP 架构
2. 应用和数据服务分离：三台服务器（硬件资源各不相同），分别是应用服务器，文件服务器和数据库服务器
3. 使用缓存改善网站性能：分为两种，缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
4. 使用应用服务器集群改善网站并发处理能力：通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
5. 数据库读写分离：数据库采用主从热备，应用服务器在写数据时访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
6. 使用反向代理和 CDN 加速网站响应：这两者基本原理都是缓存。反向代理部署在网站的中心机房，CDN 部署在网络提供商的机房
7. 使用分布式文件系统和分布式数据库系统：数据库拆分的最后手段，更常用的是业务分库
8. 使用 NoSQL 和搜索引擎：对可伸缩的分布式有更好的支持
9. 业务拆分：将整个网站业务拆分成不同的应用，每个应用独立部署维护，应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
10. 分布式服务：公共业务提取出来独立部署

阅读全文>>

标签: haproxy lvs web tcp

评论(0) 浏览(1448)

如何健壮你的后端服务？

2016-11-1 孤独求学人 架构

对每一个程序员而言，故障都是悬在头上的达摩克利斯之剑，都唯恐避之不及，如何避免故障是每一个程序员都在苦苦追寻希望解决的问题。对于这一问题，大家都可以从需求分析、架构设计 、代码编写、测试、code review、上线、线上服务运维等各个视角给出自己的答案。本人结合自己两年有限的互联网后端工作经验，从某几个视角谈谈自己对这一问题的理解，不足之处，望大家多多指出。

我们大部分服务都是如下的结构，既要给使用方使用，又依赖于他人提供的第三方服务，中间又穿插了各种业务、算法、数据等逻辑，这里面每一块都可能是故障的来源。如何避免故障？我用一句话概括，“怀疑第三方，防备使用方，做好自己”。

1 怀疑第三方

坚持一条信念：“所有第三方服务都不可靠”，不管第三方什么天花乱坠的承诺。基于这样的信念，我们需要有以下行动。

1.1 有兜底，制定好业务降级方案

如果第三方服务挂掉怎么办？我们业务也跟着挂掉？显然这不是我们希望看到的结果，如果能制定好降级方案，那将大大提高服务的可靠性。举几个例子以便大家更好的理解。

阅读全文>>

标签: 后端 服务 架构设计

评论(0) 浏览(15558)

MySQL大表优化方案

2016-8-3 孤独求学人 架构

当MySQL单表记录数过大时，增删改查性能都会急剧下降，可以参考以下步骤来优化：

单表优化

除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量：

字段

• 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED

• VARCHAR的长度只分配真正需要的空间

• 使用枚举或整数代替字符串类型

• 尽量使用TIMESTAMP而非DATETIME，

• 单表不要有太多字段，建议在20以内

• 避免使用NULL字段，很难查询优化且占用额外索引空间

• 用整型来存IP

索引

• 索引并不是越多越好，要根据查询有针对性的创建，考虑在WHERE和ORDER BY命令上涉及的列建立索引，可根据EXPLAIN来查看是否用了索引还是全表扫描

阅读全文>>

标签: mysql

评论(0) 浏览(1295)