大家好,我是曹林华(Tyler),一枚后端程序猿 ,现任沪江技术中心资深架构师 2016年加入沪江,负责技术中心中间件产品设计与架构,承担了搜索平台、ELK、分布式跟踪、实验平台等架构设计 曾任百度高级工程师职位,从事高并发Push相关的技术研发
我的博客即将入驻“云栖社区”,诚邀技术同仁一同入驻。
最近发现一本关于提高系统思维能力的书,是一本你读起来很容易接受,逻辑很清楚的书,下面我就总结下,给大家参考下 背景 一般在我们工作或者生活的过程中都会碰到下面三中情况 遇到事情突然想不清楚 表达时说不清楚 学习的时候学的慢 以上的场景可能不是所有人都遇到过,但这个不是最关键的。
最近参加了 SA Summit 2017 的技术大会分享,在这边总结下并分享一下自己是如何准备的。请老司机们多提点建议。 一、了解观众的诉求 了解需求永远是做任何事的第一步,脱离了观众的诉求都是偏题的。
当我们在做大促,类似于双十一的活动时候,老板就会跑过来问我们这些问题 1.线上服务能承受多大的访问量 2.单台服务器能承受多大的访问量 3.需要加机器吗?需要加多少台机器 这个时候,就体现出容量规划的重要性了。
最近一直在思考技术转管理过程中需要注意到的一些事情,现在就总结下分享给大家看看 在转变过程中,需要注意到一下三个方面 业务管理 团队管理 技术管理 业务管理 业务管理,主要就是管理我们需要处理的业务需求。
背景 最近一直在思考,工作这么多年下遇到的分布式系统的一下问题,以及针对这些问题提供的解决方案。 借这个机会,顺便梳理清楚这块知识,希望同大家一起探讨下 常见一致性问题 下订单减库存 在我们做的电商系统中,会有这样的一个场景:用户下单购买某个商品,然后进行扣减商品库存的场景。
前言 我们一般在做架构设计的时候,会经历过三个阶段:需求分析、概要设计和详细设计。 需求分析阶段: 主要梳理所有用例(Use case)和场景,并抽象出面向系统的用户与角色,梳理出需求提供哪些功能与非功能的需求给这些用户。
背景 作为中国最大的在线教育站点,目前沪江日志服务的用户包含网校,交易,金融,CCTalk 等多个部门的多个产品的日志搜索分析业务,每日产生的各类日志有好十几种,每天处理约10亿条(1TB)日志,热数据保留最近7天数据,冷数据永久保存。
墨菲定律 任何事情都没有表面看起来那么简单 所有事情的发展都会比你预计的时间长 会出错的事情总会出错 如果担心某个事情发生,那么它更有可能发生 墨菲定律暗示我们,如果担心某种情况会发生,那么它更有可能发生,久而久之就一定会发生。
最近在尝试梳理我们日常工作中做项目的一些小结,下面就讲这些小结做一些简单分享与交流。 首先,在我们做软件项目的过程中,一般项目中技术能力构成主要有下面三点 工程能力 关键技术能力 架构能力 不管技术是否复杂,架构是否混乱,工程能力对于任何一个项目是必不可少的。
背景 公司业务由数以百计的分布式服务沟通,每一个请求路由过来后,会经过多个业务系统并留下足迹,并产生对各种缓存或者DB的访问,但是这些分散的数据对于问题排查,或者流程优化比较有限。对于一个跨进程的场景,汇总收集并分析海量日志就显得尤为重要。
背景 随着公司业务的高速发展以及数据爆炸式的增长,当前公司各产线都有关于搜索方面的需求,但是以前的搜索服务系统由于架构与业务上的设计,不能很好的满足各个业务线的期望,主要体现下面三个问题: 不能支持对语句级别的搜索,大量业务相关的属性根本无法实现 没有任何搜索相关的指标评价体系 扩展性与维护性特别差 基于现状,对行业内的搜索服务做出充分调研,确认使用ElasticSearch做底层索引存储,同时重新设计现有搜索服务,使其满足业务方对维护性、定制化搜索排序方面的需求。
背景 在我们的日常开发中都涉及到使用tomcat做为服务器,但是我们该设置多大的线程池呢?以及根据什么原则来设计这个线程池呢? 接下来,我将介绍本人是怎么设计以及计算的。 目标 确定tomcat服务器线程池大小 具体方法 众所周知,tomcat接受一个request后处理过程中,会涉及到cpu和IO时间。