暂无个人介绍
能力说明:
了解变量作用域、Java类的结构,能够创建带main方法可执行的java应用,从命令行运行java程序;能够使用Java基本数据类型、运算符和控制结构、数组、循环结构书写和运行简单的Java程序。
阿里云技能认证
详细说明技术同学需要经常登录线上的服务器进行操作,58到家架构部/运维部/58速运技术部,联合进行了一次线上操作与线上问题排查实战演练,同学们反馈有收获,特将实战演练的问题和答案公布出来,希望对大家也有帮助。
花1分钟时间,了解聚集索引,非聚集索引,联合索引,索引覆盖。
数据库水平切分是一个很有意思的话题,不同业务类型,数据库水平切分的方法不同。本篇将以“订单中心”为例,介绍“多key”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践。
本文缘起自《一分钟了解索引技巧》的作业题。
哪一个系统的架构,不是“固定CPU,移动数据”,而是“固定数据,移动CPU”呢?
互联网分层架构演进的核心原则,是让上游更高效的获取与处理数据,让下游能屏蔽掉数据的复杂性获取细节。
个性业务代码上浮,共性业务代码服务化下沉,只是一个很小的优化点,但对于公共库解耦却是非常的有效。
使用内网域名来替换内网IP,只是一个很小的优化点,但对于IP解耦却是非常的有效。
随着业务越来越复杂,数据量越来越大,并发量越来越大,数据库的性能越来越低。好不容易找运维申请了两台机器,让DBA部署了几个实例,想把一些业务库拆分出来,却发现拆不出来,扩不了容,尴尬!
一切脱离业务的架构设计,都是耍流氓。
上一篇《服务化,耦合却更加严重》提到,执行结果的处理和业务强相关,则switch case应该放在上游业务方,而不应该放到底层通用服务。
系统分层架构有一个迭代和演进的过程(详见《互联网分层架构设计》)
如《互联网分层架构的本质》所述,互联网分层架构的本质,是数据的移动。
你见过没有注释的接口么? 你见过2000行的接口么? 你见过20个参数的接口么? 你见过什么更奇葩的接口?
赶集mysql军规
“页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术。 总数据量不大,生成静态页面数量不多的业务,非常适合于“页面静态化”优化。
技术人,谦虚一点,总是没错的。
集群信息管理,员工信息管理,告警策略管理,几篇前戏已经铺垫足够,今天,分享如何用100行代码搞定一个可扩展,通用的http监控框架。
你见过120G的日志文件么?
前天的《1分钟了解“协同过滤”》,很多同学点了赞,今天接着用通俗的语言说说“基于内容的推荐”,也保证pm弄懂。
一句话,比特币BTC(BitCoin)是,基于区块链的,能抵抗通货膨胀的,电子货币。这里有三个关键词:电子货币,抵抗通胀,基于区块链。
“把啤酒放在尿布旁,有助于提升啤酒销售量”是关联规则推荐的经典案例,今天,和大家聊聊“关联规则推荐”,正文不含任何公式,保证PM弄懂。
文章《一分钟了解nohup和&的功效》留了一个“nohup.out为啥没有包含stdout输出”的尾巴,今天把坑填了。
架构设计上,避免单点,使用故障自动转移固然能够保证系统的高可用,是否还有其他的方案,让挂掉的服务自动启动呢,这里给大伙推荐一个常见的运维工具 supervisor。
上一篇《服务挂了,怎么自动恢复?》中留了一个作业,nohup和&究竟有啥区别?不少同学进行了回复,但并不是所有同学都理解得全对,今天把自己挖的坑自己填了。
线性回归是机器学习中的概念,线性回归预测算法一般用以解决“使用已知样本对未知公式参数的估计”类问题。
互联网花了10多年的时间,已经培养出了用户在线购物的习惯,如今稍作点击,在京东11点之前下单,当天就能拿到我们中意的商品。
今天抛一个话题,根据业务现象,一起讨论其后端实现是推还是拉?
状态同步,有好友状态的同步,有群友状态的同步,有的需要实时同步,有的能够容忍延时。结合具体场景来看下,状态同步,究竟是推还是拉。
任何脱离业务的架构设计都是耍流氓。网页端收消息,究竟是推还是拉?
群消息的流程如何,接收方如何确保收到群消息,发送方如何收已读回执,究竟是拉取,还是推送,是今天要讨论的问题。
当用户量、数据量、并发量数据逐步增加之后,拉模式会慢慢扛不住了,需要升级优化,但对于“取消关注”与“发布feed”这两个写流程又会有冲击和影响。
有不少朋友问,除了掌握Java语法,还要系统学习哪些Java相关的技术,今天分享一个,互联网Java技术学习路线图。
memcache和redis是互联网分层架构中,最常用的KV缓存。不少同学在选型的时候会纠结,到底是选择memcache还是redis。
技术人如果经常线上操作DB,河边走久了,难免出现纰漏,咋办?找DBA恢复数据呗,即使恢复不了,锅总得有人背呀。
除了常见的redis/memcache等进程外缓存服务,缓存还有一种常见的玩法,进程内缓存。
允许cache miss的场景,不管是memcache还是redis,当被缓存的内容变化时,是改修改缓存,还是淘汰缓存?这是今天将要讨论的话题。
在聊数据库与缓存一致性问题之前,先聊聊数据库主库与从库的一致性问题。
缓存存储,也是数据的冗余。
在《究竟先操作缓存,还是数据库?》,有同学在评论提出,相关方案违背了“Cache Aside Pattern”的原则,故今天聊一聊Cache Aside Pattern。
缓存与数据库的操作时序,不管是《Cache Aside Pattern》中的方案,还是《究竟先操作缓存,还是数据库?》中的方案,都会遇到缓存与数据库不一致的问题。今天聊聊这个问题。
《InnoDB,5项最佳实践,知其所以然?》发布后,不少同学留言希望讲讲MySQL的InnoDB行锁机制。要细聊MySQL的行锁,难以避免的要从事务的四种隔离级别说起。
《InnoDB行锁,如何锁住一条不存在的记录?》埋了一个坑,没想到评论反响剧烈,大家都希望深挖下去。原计划写写InnoDB的锁结束这个case,既然呼声这么高,干脆全盘系统性的写写InnoDB的并发控制,锁,事务模型好了。
这些有意思的特性,你会最想尝试哪一个呢?
本质上,这些都是InnoDB锁机制的问题。
《挖坑,InnoDB的七种锁》初步说明了InnoDB中,会使用七种不同类型的锁,今天就介绍其中的第一种,自增锁(Auto-inc Locks)。
《插入InnoDB自增列,居然是表级别锁?》介绍了InnoDB所使用的七种锁中的一种,自增锁。 今天,将要介绍InnoDB另外三种:共享/排他锁,意向锁,插入意向锁。
MySQL的InnoDB的细粒度行锁,是它最吸引人的特性之一。
近期写数据库,不少朋友留言问MySQL索引底层的实现,今天简单聊一聊,少讲“是怎么样”,更多说说“为什么设计成这样”。
数据库的索引分为主键索引(Primary Inkex)与普通索引(Secondary Index)。InnoDB和MyISAM是怎么利用B+树来实现这两类索引,其又有什么差异呢?这是今天要聊的内容。