摘要：
因为我们项目上没有使用过两种，而我依旧对他们孰优孰劣比较好奇。 所以我逛了很多国内外的网站，得到了以下的结论。 首先，Redis和Memcached是两款非常给力的、快速的、并且都是使用内存做分布式缓存数据的服务。对于提升我们网站的的性能有很大的帮助（通过缓存数据、HTML片段或其他）。 接下来，通 阅读全文
摘要：
Redis 简介 Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。 Redis 与其他 key - value 缓存产品有以下三个特点： Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。 Redis不仅仅支持简单的ke 阅读全文
摘要：
一、需求缘起 【业务场景】 有一类写多读少的业务场景：大部分请求是对数据进行修改，少部分请求对数据进行读取。 例子1：滴滴打车，某个司机地理位置信息的变化（可能每几秒钟有一个修改），以及司机地理位置的读取（用户打车的时候查看某个司机的地理位置）。 void SetDriverInfo(long dr 阅读全文
摘要：
缘起：在高并发的分布式环境下，对于数据的查询与修改容易引发一致性问题，本文将分享一种非常简单但有效的优化方法。 一、业务场景 业务场景为，购买商品的过程要对余额进行查询与修改，大致的业务流程如下： （1）从数据库查询用户现有余额 SELECT money FROM t_yue WHERE uid=$ 阅读全文
摘要：
本文内容：创业型公司如何快速搭建可扩展，可落地的立体化监控平台 一、需求缘起 创业型公司有系统监控么？来看两个case： case 1：CXO大群内贴了一张“用户微信投诉”的截图 （1）CXO大群内贴了一张“用户微信投诉”的截图 （2）技术反馈“正在跟进” （3）10分钟之后，CXO询问进度，技术反 阅读全文
摘要：
一、需求缘起 大伙打开微信钱包，会发现58到家入驻了微信钱包的一级入口（如下图），这个入口流量极大，微信要求被接入的H5必须能抗住n万的qps（58到家的系统是偏交易的系统，虽然一天100w订单其实也没多少请求），这是之前的业务系统没有遇到过的，要抗住这个n万的qps的优化思路是怎么样的呢？ 这里做 阅读全文
摘要：
从0开始做垂直O2O个性化推荐 上次以58转转为例，介绍了如何从0开始如何做互联网推荐产品（回复“推荐”阅读），58转转的宝贝为闲置物品，品类多种多样，要做统一的宝贝画像比较难，而分类别做宝贝画像成本又非常高，所以更多的是进行用户画像、分类预测推荐、协同过滤推荐等个性化推荐。 有些同学反馈，他们的产 阅读全文
摘要：
从0开始做互联网推荐【产品+算法+实现】 一、58转转简介 58旗下真实个人闲置物品交易平台 二、从0开始设计推荐产品框架 （1）首页推荐：提取用户画像，根据线下提取出的用户年龄、性别、品类偏好等在首页综合推荐宝贝 （2）宝贝详情页推荐：买了还买，看了还看类的关联宝贝推荐 （3）附近推荐：和首页推荐 阅读全文
摘要：
一、推荐系统架构介绍 推荐系统是一个微庞大的工程、算法与业务综合的系统，其主要分为三大子系统： 1）线下推荐子系统； 2）线上推荐子系统； 3）效果评估子系统； 后文将重点讨论以上三大子系统的设计与实现。 二、线下推荐子系统 线下推荐子系统又主要分为线下挖掘模块、数据管理工具两大部分。 线下挖掘模块 阅读全文
摘要：
好的架构化是进化而来的，不是设计出来的 58沈剑 核心内容：58同城流量从小到大过程中，架构是如何演进的？遇到了哪些问题？以及如何解决这些问题？ 核心观点：好的架构不是设计出来的，而是进化而来的。 如何演进：站点流量在不同阶段，会遇到不同的问题，找到对应阶段站点架构所面临的主要问题，在不断解决这些问 阅读全文
摘要：
通过上篇文章的介绍，知道了要实施微服务，首先要搞定RPC框架，RPC框架分为客户端部分与服务端部分。 RPC-client的部分又分为： （1）序列化反序列化的部分（上图中的1、4） （2）发送字节流与接收字节流的部分（上图中的2、3） 前一篇文章讨论了序列化与范序列化的细节，这一篇文章将讨论发送字 阅读全文
摘要：
通过上篇文章的介绍，知道了要实施微服务，首先要搞定RPC框架，RPC框架的职责要向【调用方】和【服务提供方】屏蔽各种复杂性： （1）让调用方感觉就像调用本地函数一样 （2）让服务提供方感觉就像实现一个本地函数一样来实现服务 整个RPC框架又分为client部分与server部分： RPC-clien 阅读全文
摘要：
今天开始聊一些微服务的实践，第一块，RPC框架的原理及实践，为什么说要搞定微服务架构，先搞定RPC框架呢？ 一、需求缘起 服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦，如下图： 服务A是欧洲团队提供服务，欧洲团队的技术背景是Java，可以用Java实现服务 阅读全文
摘要：
一、互联网架构为什么要进行服务化-总结 上一篇和大伙交流了一下，随着数据量、并发量、业务复杂度的增长，互联网架构会出现以下问题： （1）代码到处拷贝 （2）底层复杂性扩散 （3）基础库（so/jar/dll）耦合 （4）SQL质量得不到保障，业务相互影响 （5）数据库耦合 “服务化”是一个很好的解决 阅读全文
摘要：
近期参加一些业界的技术大会，“微服务架构”的话题非常之火，也在一些场合聊过服务化架构实践，最近几期文章期望用通俗易懂的语言聊聊了个人对服务化以及微服务架构的理解，希望能给大伙一些启示。如果有遗漏，也欢迎大家补充。 一、互联网高可用架构，为什么要服务化？ 【服务化之前高可用架构】 在服务化之前，互联网 阅读全文
摘要：
一、缘起 （1）并发量大，流量大的互联网架构，一般来说，数据库上层都有一个服务层，服务层记录了“业务库名”与“数据库实例”的映射关系，通过数据库连接池向数据库路由sql语句以执行： 如上图：服务层配置用户库user对应的数据库实例物理位置为ip（其实是一个内网域名）。 （2）随着数据量的增大，数据要 阅读全文
摘要：
一、缘起 mysql主从复制，读写分离是互联网用的非常多的mysql架构，主从复制最令人诟病的地方就是，在数据量较大并发量较大的场景下，主从延时会比较严重。 为什么mysql主从延时这么大？ 回答：从库使用【单线程】重放relaylog。 优化思路是什么？ 回答：使用单线程重放relaylog使得同 阅读全文
摘要：
需求缘起 大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用“一主多从，读写分离，冗余多个读库”的数据库架构来提升数据库的读性能。 这种架构的一个潜在缺点是，业务方有可能读取到并不是最新的旧数据： （1）系统先对DB-master进行了一个写操作，写主库 阅读全文
摘要：
本文主要讨论这么几个问题： （1）数据库主从延时为何会导致缓存数据不一致 （2）优化思路与方案 一、需求缘起 上一篇《缓存架构设计细节二三事》中有一个小优化点，在只有主库时，通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步，读写分离的数据库架构下，有可能出现脏 阅读全文
摘要：
本文主要讨论这么几个问题： （1）啥时候数据库和缓存中的数据会不一致 （2）不一致优化思路 （3）如何保证数据库与缓存的一致性 一、需求缘起 上一篇《缓存架构设计细节二三事》（点击查看）引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库”这个点是大家讨论的最多的。 上篇文 阅读全文