Browsed by
标签:Redis

ZooKeeper实际应用案例-开发实战

ZooKeeper实际应用案例-开发实战

閱讀本文約花費: 12 (分鐘) 本文主要介绍通过实际工作中的一个例子,讲解zookeeper是如何帮我解决分布式问题,以此引导大家发现自己系统中可以应用zookeeper的场景。 项目背景介绍 首先给大家介绍一下本文描述项目的情况。这是一个检索网站,它让你能在几千万份复杂文档数据中检索出你所需要的文档数据。为了加快检索速度,项目的数据分布在100台机器的内存里,我们称之为数据服务器。除了数据,这100台机器上均部署着检索程序。这些server之外,还有数台给前端提供接口的搜索server,这些机器属一个集群,我们称之为检索服务器。当搜索请求过来时,他们负责把搜索请求转发到那100台机器,待所有机器返回结果后进行合并,最终返回给前端页面。结构如下图: 面临问题 网站上线之初,由于数据只有几百万,所以数据服务器只有10多台。是一个规模比较小的分布式系统,当时没有做分布式系统的协调,也能正常工作,偶尔出问题,马上解决。但是到了近期,机器增长到100台,网站几乎每天都会出现问题,导致整个分布式系统挂掉。问题原因如下: 数据服务器之前没有做分布式协调。对于检索服务器来说,并不知道哪些数据服务器还存活,所以检索服务器每次检索,都会等待100台机器返回结果。但假如100台数据服务中某一台死掉了,检索服务器也会长时间等待他的返回。这导致了检索服务器积累了大量的请求,最终被压垮。当所有的检索服务器…

Read More Read More

微服务网关

微服务网关

閱讀本文約花費: 14 (分鐘) 本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 一、前言 随着微服务的兴起,基于其业务耦合性低、负载能力强、服务边界清晰等优点,大家纷纷使用微服务架构来实现新系统或进行老系统的改造。微服务在带来诸多好处的同时,也有一些问题需要解决,比如:如何做到有效拆分、减少服务间调用,如何统一管理所有服务的接口,如何进行自动化部署等。本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 二、API网关简介 API网关,顾名思义,是统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。下图为微服务架构的简单示意图,网关起到的作用一目了然。 三、API网关的作用 为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。 所以实现或者选择一个好的API网关,是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署,要尽可能的减少接触面…

Read More Read More

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

閱讀本文約花費: 51 (分鐘)环境搭建概述 1.K8S是什么? K8S全称是Kubernetes,是一个全新的基于容器技术的分布式架构领先方案,基于容器技术,目的是实现资源管理的自动化,以及跨多个数据中心的资源利用率的最大化。 如果我们的系统设计遵循了kubernetes的设计思想,那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块,都可以使用K8S来管理,我们不必再费心于负载均衡的选型和部署实施问题,不必再考虑引入或自己开发一个复杂的服务治理框架,不必再头疼与服务监控和故障处理模块的开发。总之,使用kubernetes提供的解决方案,会大大减少开发成本,同时可以将精力更加集中于业务本身,而且由于kubernetes提供了强大的自动化机制,所以系统后期的运维难度和运维成本大幅降低。 2.为什么要用K8S? Docker 这个新兴的容器化技术当前已经被很多公司所采用,其从单机走向集群已成必然,而云计算的蓬勃发展正在加速这一进程。Kubernetes 作为当前唯一被业界广泛认可和看好的 Docker 分布式系统解决方案。可以预见,在未来几年内,会有大量的新系统选择它,不管是运行在企业本地服务器上还是被托管到公有云上。 3.使用K8S有哪些好处? 使用Kubernetes就是在全面部署微服务架构。微服务架构的核心就是将一个巨大的单体应用分解为很多小的互相连接的微服务,一个微服…

Read More Read More

线程池运用不当的一次线上事故

线程池运用不当的一次线上事故

閱讀本文約花費: 11 (分鐘)在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高单个线程的复用能力,进一步提升整体性能。 今天遇到了一个比较典型的线上问题,刚好和线程池有关,另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点,同时整个调查思路可以借鉴,特此记录和分享一下。 01 业务背景描述 该线上问题发生在广告系统的核心扣费服务,首先简单交代下大致的业务流程,方便理解问题。 绿框部分即扣费服务在广告召回扣费流程中所处的位置,简单理解:当用户点击一个广告后,会从C端发起一次实时扣费请求(CPC,按点击扣费模式),扣费服务则承接了该动作的核心业务逻辑:包括执行反作弊策略、创建扣费记录、click日志埋点等。 02 问题现象和业务影响 12月2号晚上11点左右,我们收到了一个线上告警通知:扣费服务的线程池任务队列大小远远超出了设定阈值,而且队列大小随着时间推移还在持续变大。详细告警内容如下: 相应的,我们的广告指标:点击数、收入等也出现了非常明显的下滑,几乎同时发出了业务告警通知。其中,点击数指标对应的曲线表现如下: 该线上故障发生在流量高峰期,持续了将近30分钟后才恢复正常。 03 问题调查和事故解决过程 下面…

Read More Read More

基于 Docker 和 Kubernetes 的微服务实践

基于 Docker 和 Kubernetes 的微服务实践

閱讀本文約花費: 12 (分鐘) 本文来自微信公众号,本文介绍基于Docker和Kubernetes的整个微服务实践过程,我们在实践微服务过程中做了9件重要的事情, 简化了操作流程,提高了工作效率。 一、微服务化 微服务架构 微服务 是将单一的应用程序拆分成多个微小的服务,各个小服务之间松耦合,高内聚,每个小的服务可以单独进行开发,不依赖于具体的编程语言,也可以使用不同的数据存储技术,各个服务可以独立部署,拥有各自的进程,相互之间通过轻量化的机制进行通信(如基于HTTP的API接口),所有的服务共同实现具体的业务功能。 客户端与服务端通信有2种方式,第一种是客户端直接与各个微服务进行通信,这样的架构有4个缺点: (1)多次服务请求,效率低; (2)对外暴露服务接口; (3)接口协议无法统一; (4)客户端代码复杂,服务端升级困难。 第二种方式是由API网关统一代理各个服务,对外提供统一的接口协议,该架构有3 个优势: (1)封装服务接口细节,减少通信次数; (2)统一通信协议,减少客户端代码耦合; (3)统一鉴权,流控,防攻击; 在该架构下,网关也有可能成为系统瓶颈。 相应地,这2种架构也带来了2种服务注册发现的方式,第一种是客户端通过向服务的注册中心查询微服务的地址与其通信,第二种是增加统一的API网关来查询。前者会增加客户端的复杂度,开发成本高,第二种操作会显得更加简洁,因此我…

Read More Read More

Redis的内存和实现机制

Redis的内存和实现机制

閱讀本文約花費: 23 (分鐘)1. Reids内存的划分# 数据 内存统计在used_memory中 进程本身运行需要内存 Redis主进程本身运行需要的内存占用,代码、常量池等 缓冲内存,客户端缓冲区、复制积压缓冲区、AOF缓冲区。有jemalloc分配内存,会统计在used_memory中 内存碎片 Redis在分配、回收物理内存过程中产生的。内存碎片不会统计在used_memory中。如果Redis服务器中的内存碎片已经很大,可以通过安全重启的方式减小内存碎片:因为重启之后,Redis重新从备份文件中读取数据,在内存中进行重排,为每个数据重新选择合适的内存单元,减小内存碎片。 2. Redis的数据存储的细节# 涉及到内存分配器jemalloc, 简单动态字符串(SDS),5种值类型对象的内部编码,redisObject, DictEntry: Redis 是key-value数据库,因此对每个键值对都会有一个dictEntry,里面存储了指向Key和Value的指针;next指向下一个dictEntry,与本Key-Value无关 Key: 并不是以字符串存储,而是存储在SDS结构中 RedisObject: 5种值对象不是直接以对应的类型存储的,而是被封装为redisObject来存储 jemalloc: 无论是DictEntry对象,还是redisObject, SD…

Read More Read More

AWS Solution Architecture Associate 认证攻略

AWS Solution Architecture Associate 认证攻略

閱讀本文約花費: 55 (分鐘)AWS认证介绍 AWS Certified Solutions Architect 系列认证是亚马逊从2013年开始推出的对云计算架构师能力的官方认证。考试不仅考察应试者对AWS相关云服务的熟悉程度,题目也多来源于实际中要解决的问题,要求应试者有全面的架构设计经验和积累,所以含金量很高。在美国招聘网站glassdoor上,AWS solution architect的身价平均在10万美金以上,可见业界对这个认证的认可程度。 它在国内的认可程度如何呢?根据我和考试认证中心的工作人员聊天打听到,国内来考试的分两类人,一类是工作单位和亚马逊有合作关系,单位出钱要求通过。另一类是云计算这个行业的早起的鸟儿,他们想充实自己的职业技能,在云计算这个浪潮中能有一席之地。所以相对来说了解和报考的人还是少数。 不过想顺利通过这个考试并不容易。一方面考试全程英文阅读量大。另一方面复习资料缺乏,只能通过官方的FAQ文档和白皮书进行学习,自学效率非常低。对于初次接触AWS云服务认证的同学来说,不花2,3个月的时间认证准备,是很难通过的。就算作者身边那些有2,3年AWS云服务使用经验的架构师,想裸考通过,成功率也几乎为零。所以,打算通过这个考试,一定要认真对待,规划好时间充分准备。 关于AWS认证考试更多的介绍,大家还可以参考网上刘涛同学的文章http://www.csdn….

Read More Read More

关于阿里云经典网络的问题

关于阿里云经典网络的问题

閱讀本文約花費: 10 (分鐘)昨天写了一篇《科普一下公有云的网络》,今天收到了阿里云官方的回复,并还动用了一些微博上的IT圈的号来转这个“澄清”。 【澄清】1.文章存在事实错误,阿里云经典网络内网默认不互通;2.经典网络下,用户只有在设置安全规则开放过多协议和过大CIDR网段如0.0.0.0/0的情况下才能被访问;3.新用户可优先选择阿里云VPC;4.经典网络存量服务器向VPC迁移功能正在内测;5.正确设置指南:O网页链接​ (注:其实,阿里云和一些用户并没有认真阅读我的文章,如果认真阅读了就会发现阿里云官方是在映证我之前的文章的大部分的观点的) 我本来想推动更成熟更为安全的VPC解决方案的,但发现阿里云官方的这个言论相当的误导用户,似乎还是想让用户信任阿里云的经典网络。既然这样,我觉得我非常有必要写下这一篇文章来更为详细地说明一下这个事。 2013年的阿里云 2013年,我在阿里商家业务部做聚石塔,聚石塔的底层是阿里云。当时,聚石塔的安全问题很严重,有很多商家和买家的业务数据外泄,所以,成立了一个专门负责安全的小组。阿里安全部门也专门派人来强力支持。 当时有一个很大的安全问题是——阿里云的内网多个租户居然是通的。我团队的一个花名叫焦义的同学做了一个这样的测试——用自己的钱在阿里云上开了一台机器,然后随便访问聚石塔里的用户的机器,当时做这个测试的时候,阿里安全部门的Suddy、商…

Read More Read More

科普一下公有云的网络

科普一下公有云的网络

閱讀本文約花費: 7 (分鐘)​​@admin一乐 同学发了一篇微博(http://weibo.com/1819367693/EwZFypkK6)说了一下因为一个安全问题的疏忽中招的事。​大意是redis有一个可以提权访问服务器安全漏洞,但是因为一乐家的redis服务器没有暴露给公网,所以一开始也就没有特别在意,不料还是被攻破了,原因虽然是这个服务器没有暴露在公网,但是因为阿里云的内网各个租户是可以互相访问的,所以,也相当于暴露给了别人…… 我简单地回复了一下这个事,就说让我想到了以前和阿里云解决多租户内网必需隔离的事(是什么事我也没细说,只是简单的感叹一下)。结果引发了些敏感的人的质疑和口水。那些口水对我来说无意义,不过,这个期间看到似乎大家对公有云的网络并不是很明白,所以,写下这篇文,希望大家都注意起来,以免出现公有云上的安全问题。 安全组 阿里云的内网是经典网络,也就是说,不同的租户是互通的,如果你只想让你自己的机器访问的话,那么你要给你每一台机器都配上互相可以访问的安全组。安全组是AWS的Security Group的中文翻译,说白了就是防火墙,你可以简单理解为你Windows机器上的防火墙——其中标明了网络出站和入站的规则。 这种经典网络就好像一个公司内的办公网络一下,所有员工的电脑都可以互相ping通和访问的(这就是为会什么有些病毒可以在公司内网里泛滥)。如果你不想让别…

Read More Read More

阿里云服务器被挖矿程序minerd入侵的终极解决办法

阿里云服务器被挖矿程序minerd入侵的终极解决办法

閱讀本文約花費: 4 (分鐘)      突然发现阿里云服务器CPU很高,几乎达到100%,执行 top c 一看,吓一跳,结果如下: 3798 root 20 0 386m 7852 1272 S 300.0 0.1 4355:11 /tmp/AnXqV -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:443 -u 4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofT5844 root 20 0 3448m 292m 14m S 1.7 3.7 26:02.07 /usr/java/default/bin/java -Xms64M -Xmx1G -Djava.util.logging.config.file=logging.properties -Djava.security.auth.login.config=/us2500 root 20 0 220m 9.9m 5176 S 0.3 0.1 0:09.02 /tmp/ddg.2171 root 20 0 19360 1532 1232 S 0.0 0.0 0:00.61 /sbin/init  有个进程minerd尽然占用了300%的CPU, 百度了一下,貌似服务器…

Read More Read More