Mobabel Blog

0

[转]大型网站压力测试及优化方案

1. 0 木桶理论应用在系统优化中 木桶理论又称短板理论,其核心思想是一只木桶盛水多少,并不取决于最高的木板,而取决于最短的那块木板。 木桶原理应用在系统分析中,即系统的最终性能取决于系统中性能表现最差的组件,为了提升系统整体性能,对系统中表现最差的组件进行优化可以得到最好的效果。

[转]详解tomcat的连接数与线程池 0

[转]详解tomcat的连接数与线程池

1. 前言 在使用tomcat时,经常会遇到连接数、线程数之类的配置问题,要真正理解这些概念,必须先了解Tomcat的连接器(Connector)。 在前面的文章 详解Tomcat配置文件server.xml 中写到过:Connector的主要功能,是接收连接请求,创建Request和Response对象用于和请求端交换数据;然后分配线程让Engine(也就是Servlet容器)来处理这个请求,并把产生的Request和Response对象传给Engine。当Engine处理完请求后,也会通过Connector将响应返回给客户端。 可以说,Servlet容器处理请求,是需要Connector进行调度和控制的,Connector是Tomcat处理请求的主干,因此Connector的配置和使用对Tomcat的性能有着重要的影响。这篇文章将从Connector入手,讨论一些与Connector有关的重要问题,包括NIO/BIO模式、线程池、连接数等。 根据协议的不同,Connector可以分为HTTP Connector、AJP Connector等,本文只讨论HTTP Connector。

[转]详解Tomcat 配置文件server.xml 0

[转]详解Tomcat 配置文件server.xml

1. 前言 Tomcat隶属于Apache基金会,是开源的轻量级Web应用服务器,使用非常广泛。server.xml是Tomcat中最重要的配置文件,server.xml的每一个元素都对应了Tomcat中的一个组件;通过对xml文件中元素的配置,可以实现对Tomcat中各个组件的控制。因此,学习server.xml文件的配置,对于了解和使用Tomcat至关重要。 本文将通过实例,介绍server.xml中各个组件的配置,并详细说明Tomcat各个核心组件的作用以及各个组件之间的相互关系。 说明:由于server.xml文件中元素与Tomcat中组件的对应关系,后文中为了描述方便,“元素”和“组件”的使用不严格区分。

Bildergebnis für lego movie 2 0

[转]深入学习Redis(5):集群

1. 2. 前言 在前面的文章中,已经介绍了Redis的几种高可用技术:持久化、主从复制和哨兵,但这些方案仍有不足,其中最主要的问题是存储能力受单机限制,以及无法实现写操作的负载均衡。 Redis集群解决了上述问题,实现了较为完善的高可用方案。本文将详细介绍集群,主要内容包括:集群的作用;集群的搭建方法及设计方案;集群的基本原理;客户端访问集群的方法;以及其他实践中需要的集群知识(集群扩容、故障转移、参数优化等)。

0

[转]深入学习Redis(4):哨兵

1. 2. 前言 在 深入学习Redis(3):主从复制 中曾提到,Redis主从复制的作用有数据热备、负载均衡、故障恢复等;但主从复制存在的一个问题是故障恢复无法自动化。本文将要介绍的哨兵,它基于Redis主从复制,主要作用便是解决主节点故障恢复的自动化问题,进一步提高系统的高可用性。 文章主要内容如下:首先介绍哨兵的作用和架构;然后讲述哨兵系统的部署方法,以及通过客户端访问哨兵系统的方法;然后简要说明哨兵实现的基本原理;最后给出关于哨兵实践的一些建议。文章内容基于Redis 3.0版本。

0

[转]深入学习Redis(3):主从复制

1. 前言 在前面的两篇文章中,分别介绍了Redis的内存模型和Redis的持久化。 在Redis的持久化中曾提到,Redis高可用的方案包括持久化、主从复制(及读写分离)、哨兵和集群。其中持久化侧重解决的是Redis数据的单机备份问题(从内存到硬盘的备份);而主从复制则侧重解决数据的多机热备。此外,主从复制还可以实现负载均衡和故障恢复。 这篇文章中,将详细介绍Redis主从复制的方方面面,包括:如何使用主从复制、主从复制的原理(重点是全量复制和部分复制、以及心跳机制)、实际应用中需要注意的问题(如数据不一致问题、复制超时问题、复制缓冲区溢出问题)、主从复制相关的配置(重点是repl-timeout、client-output-buffer-limit slave)等。

0

[转]深入学习Redis(2):持久化

1. 2. 前言 在上一篇文章中,介绍了Redis的内存模型,从这篇文章开始,将依次介绍Redis高可用相关的知识——持久化、复制(及读写分离)、哨兵、以及集群。 本文将先说明上述几种技术分别解决了Redis高可用的什么问题;然后详细介绍Redis的持久化技术,主要是RDB和AOF两种持久化方案;在介绍RDB和AOF方案时,不仅介绍其作用及操作方法,同时介绍持久化实现的一些原理细节及需要注意的问题。最后,介绍在实际使用中,持久化方案的选择,以及经常遇到的问题等。

0

[转]深入学习Redis(1):Redis内存模型

1. 前言 Redis是目前最火爆的内存数据库之一,通过在内存中读写数据,大大提高了读写速度,可以说Redis是实现网站高并发不可或缺的一部分。 我们使用Redis时,会接触Redis的5种对象类型(字符串、哈希、列表、集合、有序集合),丰富的类型是Redis相对于Memcached等的一大优势。在了解Redis的5种对象类型的用法和特点的基础上,进一步了解Redis的内存模型,对Redis的使用有很大帮助,例如: 1、估算Redis内存使用量。目前为止,内存的使用成本仍然相对较高,使用内存不能无所顾忌;根据需求合理的评估Redis的内存使用量,选择合适的机器配置,可以在满足需求的情况下节约成本。 2、优化内存占用。了解Redis内存模型可以选择更合适的数据类型和编码,更好的利用Redis内存。 3、分析解决问题。当Redis出现阻塞、内存占用等问题时,尽快发现导致问题的原因,便于分析解决问题。 这篇文章主要介绍Redis的内存模型(以3.0为例),包括Redis占用内存的情况及如何查询、不同的对象类型在内存中的编码方式、内存分配器(jemalloc)、简单动态字符串(SDS)、RedisObject等;然后在此基础上介绍几个Redis内存模型的应用。 在后面的文章中,会陆续介绍关于Redis高可用的内容,包括主从复制、哨兵、集群等等,欢迎关注。

0

[转]Flink靠什么征服阿里工程师?

时下,谈及大数据,不得不提到热门的下一代大数据计算引擎 Apache Flink(以下简称 Flink)。 本文将结合 Flink 的前世今生,从业务角度出发,向大家娓娓道来:为什么阿里选择了 Flink? 1. 为什么阿里选择了 Flink 随着人工智能时代的降临,数据量的爆发,在典型的大数据的业务场景下数据业务最通用的做法是:选用批处理的技术处理全量数据,采用流式计算处理实时增量数据。 在绝大多数的业务场景之下,用户的业务逻辑在批处理和流处理之中往往是相同的。 但是,用户用于批处理和流处理的两套计算引擎是不同的。因此,用户通常需要写两套代码。毫无疑问,这带来了一些额外的负担和成本。 阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问题,所以阿里就在想,我们能不能有一套统一的大数据引擎技术,用户只需要根据自己的业务逻辑开发一套代码。 这样在各种不同的场景下,不管是全量数据还是增量数据,亦或者实时处理,一套方案即可全部支持,这就是阿里选择 Flink 的背景和初衷。 目前开源大数据计算引擎有很多选择,流计算如 Storm、Samza、Flink、Kafka Stream 等,批处理如 Spark、Hive、Pig、Flink 等。 而同时支持流处理和批处理的计算引擎,只有两种选择: Apache Spark。 Apache Flink。 从技术,生态等各方面的综合考虑。首先,Spark 的技术理念是基于批来模拟流的计算。而 Flink 则完全相反,它采用的是基于流计算来模拟批计算。 从技术发展方向看,用批来模拟流有一定的技术局限性,并且这个局限性可能很难突破。...