Mobabel

Just One Pure Coder

Mobabel Blog

[汇总]IDEA技巧 0

Toolchain

[汇总]IDEA技巧

    整理了一些 IDEA 中比较骚的技巧 一个表达式后按下点号 . ，然后输入一些提示或者在列表中选择一个候选项 这样配置：让你的 IDEA 好用到飞起来 IDEA万能快捷键，你必须知道的17个实用技巧，提升撸码效率！ 手把手教你如何免费且光荣地使用正版IntelliJ IDEA

千万级用户的大型网站如何设计其高并发架构 0

SOA Architect to MS Architect

千万级用户的大型网站如何设计其高并发架构

目录 （1）单块架构 （2）初步的高可用架构 （3）千万级用户量的压力预估 （4）服务器压力预估 （5）业务垂直拆分 （6）用分布式缓存抗下读请求 （7）基于数据库主从架构做读写分离 （8）总结 本文将会从一个大型的网站发展历程出发，一步一步的探索这个网站的架构是如何从单体架构，演化到分布式架构，然后演化到高并发架构的。

解决AWS Lambda不断重启的问题 0

AWS

解决AWS Lambda不断重启的问题

今天一个在测试部署在AWS Lambda的Function时遇到个问题，这个Function很简单，基于Java开发，通过httpclient发送请求到第三方服务器再发送给client收到的数据。从CloudWatch Logs里看，经常是一个请求耗时10秒左右，但紧接着的另一个请求就很正常，2-3秒结束。

[转]谈谈服务雪崩、降级与熔断 0

High Concurrency, Circuit Breaker, Rate Limit, Load Balance,etc...

[转]谈谈服务雪崩、降级与熔断

首先，之所以谈这个话题呢，是发现现在很多人对微服务的设计缺乏认识，所以写一篇扫盲文。当然，考虑到目前大多微服务的文章都是口水文，烟哥争取将实现方式讲透，点清楚，让大家有所收获！ OK，我要先说明一下，我有很长一段时间将服务降级和服务熔断混在一起，认为是一回事！

[转]分布式缓存中的一致性哈希算法 0

Distributed Global ID Generator

[转]分布式缓存中的一致性哈希算法

一致性哈希算法在分布式缓存领域的 MemCached，负载均衡领域的 Nginx 以及各类 RPC 框架中都有广泛的应用 它主要是为了解决传统哈希函数添加哈希表槽位数后要将关键字重新映射的问题。 本文会介绍一致性哈希算法的原理及其实现，并给出其不同哈希函数实现的性能数据对比，探讨Redis 集群的数据分片实现等，文末会给出实现的具体 github 地址。

[转]蚂蚁金服 30 万级测试用例的核心应用如何分钟级运行？ 0

CI & Automation Test

[转]蚂蚁金服 30 万级测试用例的核心应用如何分钟级运行？

背景与挑战——又稳又快 互联网行业的最主要属性是快，一方面是量的快速增长；另一方面是业务场景的多样化变更。每年的交易量都增长得非常快速，同时业务也快速丰富起来，之前可能只有线上电商担保交易，现在新增了许多金融属性的业务如花呗、借呗、相互保，甚至还有跨境支付。同时，蚂蚁金服具备的金融属性，要确保监管合规和资金安全，需要把稳放到首位，我们需要在这个稳的基础上去快速创新以满足市场的快速变化。也就是说要“又稳又快”。 把又稳又快深入到软件开发，「稳」要求软件质量可靠；「快」体现在研发队伍快速扩张和代码量的快速增长。在这种背景下，对于 CI（持续集成）的研究和改造成为保障软件质量可靠又快速交付的有效手段。

[转]数据可视化图表选型 0

Big Data Practice

[转]数据可视化图表选型

常听到一句话，“能用图描述的就不用表，能用表就不用文字”。这句话也直接的表明了：在认知上，大家对于图形的敏感度远比文字高。 但同时我们也面临着这样一些问题： 写 PPT、做 demo 时，心中有万千想法和海量数据想要去展现，但总是最后还是以文字和枯燥的图表堆叠呈现了出来，苦于怎么把这些数据展现的直观、性感、一看就懂。这时候，在心里怎么想和手上怎么画之间，差了一座“理解图表内涵”的桥梁了。

[转]分库分表无限扩容 0

Database Partitioning&Scaling

[转]分库分表无限扩容

正常情况下的服务演化之路 让我们从最初开始。 1、单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每个程序员都经历过。 2、RPC 应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了，如下图： 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接 DB 的，只需要连接缓存即可，那么就可以做成分离的，减少 DB 宝贵的连接。如下图： 我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。 3、分库分表 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL 操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过 ID hash 或者 range 的方式都可以。如下图： 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和 RPC 的问题有点类似：数据库连接过多！！！ 通常，我们的 RPC...