架构
后海hh
爱好技术,喜欢专研底层和看流行的开源代码,有一定的代码洁癖,会定时优化重构代码,使其扩展性维护性和性能更好
展开
-
缓存穿透、并发和失效的解决方案
我们在用缓存的时候,不管是Redis或者Memcached,基本上会通用遇到以下三个问题:缓存穿透缓存并发缓存失效缓存穿透注:上面三个图会有什么问题呢?我们在项目中使用缓存通常都是先检查缓存中是否存在,如果存在直接返回缓存内容,如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的转载 2016-07-14 16:01:05 · 4263 阅读 · 0 评论 -
一个由多线程而引发内存溢出故障的案例分析
一日凌晨,手机疯狂报警,短信以摧枯拉朽之势瞬间以百条的速度到达,我在睡梦中被惊醒,看到短信的部分内容如下:看到这个错误,我的第一感觉是创建了大量的线程,并且资源没有被回收,但是报错的却是其中一台应用服务器,表象看不太像是程序的问题,而此时在凌晨并发量也不应该会有这么大啊?同时我们不能因为报错暂停服务使用,而影响商户,所以决定要先解决问题,于是采用必杀技重启这台服务器,观察一小时内存转载 2016-08-05 09:23:45 · 6936 阅读 · 0 评论 -
MySQL大表优化方案
当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化:单表优化除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量:字段尽量使转载 2016-08-05 09:18:29 · 533 阅读 · 0 评论 -
分库后的分页处理
在数据量过大以后,通常都会进行分库操作,把一张表拆分到不同数据库中例如 tb1 表被拆分到3个库中,分库1、分库2、分库3现在想执行分页操作SELECT c1 FROM tb1 ORDER BY c1 LIMIT 4, 2如何处理呢?查了一些数据库中间件的资料,有一个通用的思路:到每个分库中取出从0开始、到目标结果集的最后一条记录,汇总到一起,进行排序,然后转载 2016-08-05 09:16:31 · 522 阅读 · 0 评论 -
性能优化的十个建议
1、不进行升级。很多人抱怨他们的系统不够快,并通过编写更好的算法和数据结构来寻求帮助,Thompson认为实际上“他们所需的仅仅就是进行升级”。升级操作系统、JVM、CLR等等。不进行升级的常见借口就是“在新版本中可能会有bug。”为了避免这种状况,可以进行定期的持续集成和测试,这应该是开发流程的基础组成部分。Thompson以一个实时系统进行了例证,开发人员针对新版本的数据库进行转载 2016-08-05 09:14:33 · 966 阅读 · 0 评论 -
Netty的高性能架构之道
Netty是一个高性能、异步事件驱动的NIO框架,它提供了对TCP、UDP和文件传输的支持,作为一个异步NIO框架,Netty的所有IO操作都是异步非阻塞的,通过Future-Listener机制,用户可以方便的主动获取或者通过通知机制获得IO操作结果。作为当前最流行的NIO框架,Netty在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用,一些业界著名的开源转载 2016-07-27 13:50:47 · 2560 阅读 · 0 评论 -
电商抢购服务高并发设计
服务介绍限时抢购又称闪购,英文Flash sale,起源于法国网站Vente Privée。闪购模式即是以互联网为媒介的B2C电子零售交易活动,以限时特卖的形式,定期定时推出国际知名品牌的商品,一般以原价1-5折的价格供专属会员限时抢购,每次特卖时间持续5-10天不等,先到先买,限时限量,售完即止。顾客在指定时间内(一般为20分钟)必须付款,否则商品会重新放到待销售商品的行列里。转载 2016-07-27 13:48:17 · 3246 阅读 · 0 评论 -
mysql查询更新时的锁表机制分析(只介绍了MYISAM)
为了给高并发情况下的mysql进行更好的优化,有必要了解一下mysql查询更新时的锁表机制。一、概述MySQL有三种锁的级别:页级、表级、行级。MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking);BDB存储引擎采用的是页面锁(page-level locking),但也支持表级锁;InnoDB存储引擎既支持行级锁(row-level lo转载 2016-07-16 18:16:41 · 3671 阅读 · 3 评论 -
分布式多活的异地多活设计四大误区
其实大部分问题我们之前也遇到过,这些问题当时也困扰着我们,后来我们经过讨论和思考,发现其实很多时候我们困扰的主要原因是过于“追求完美的异地多活方案”,这样导致“异地多活”设计中出现很多了的思维误区,而如果不意识到这些思维误区,就会陷入死胡同,导致无法实现真正的“异地多活”方案。接下来我将总结常见的思维误区,看看你踩中了哪个坑?1所有业务异地多活“异地多活”是为了保证业务的高可用转载 2016-07-15 09:28:17 · 9750 阅读 · 0 评论 -
一个可供参考的Java高并发异步应用案例
泰康在线微信公众号系泰康在线财产保险股份有限公司旗下平台,希望可以通过持续不断的创新,提升客户对于保险的认知及体验,通过对大数据技术的应用,精准的为客户设计产品以及提供服务。泰康在线微信公众号,现有1000多万粉丝。在日常的运营中,借助于红包奖励、卡券分享、消息通知、微信分享等手段,通过好的内容,好的活动、好的产品以及相应的精准营销来增强用户的粘性和活跃度。在日常运营中,公众号会通过给用户转载 2016-07-14 16:04:49 · 4181 阅读 · 0 评论 -
MongoDB在58同城的应用实践
58同城作为中国最大的生活服务平台,涵盖了房产、招聘、二手、二手车、黄页等核心业务。58同城发展之初,大规模使用关系型数据库(SQL Server、MySQL等),随着业务扩展速度增加,数据量和并发量演变的越来越有挑战,此阶段58的数据存储架构也需要相应的调整以更好的满足业务快速发展的需求。MongoDB经过几个版本的迭代,到2.0.0以后,变的越来越稳定,它具备的高性能、高扩展性、Aut转载 2016-08-05 09:26:08 · 1365 阅读 · 0 评论