Redis

此篇转自: http://hi.ktsee.com/635.html 原文很棒,之所以转过来当轮子是因为想改成自己看的习惯的方式,方便以后查看. 其实很在之前已经写了一篇关于 内网转发服务的文章 ，只是那次是使用shell反向主动连接，保持转发。这次因为有了一个新的需求，有两台服务器，其中一台有公网ip，另一台没有公网ip，只提供redis服务，供前面那台服务器内网访问，而现在有时候需要通过公网直接访问内网服务器上的redis服务测试用，这时候更好的解决办法是端口转发，即将公网ip的服务器转发到内网，实现直接访问内网服务器上的服务。 这个有点相当于路由器设置页面里的NAT端口转发，只是这里是用iptables命令来实现，因此做一下记录，也为有和我同样需求的同学提供一些参考。 需求概述 假设我们有两台Linux服务器，分别是Server A跟Server B，它们在统一内网中，其中A有公网ip，而B没有： Server A: 内网192.168.0.1，公网123.123.123.123 Server B: 内网192.168.0.2，公网IP无，端口6543为Redis服务端口 生产环境中，Server A提供外网服务，同时通过 192.168.0.2:6543 内部直接访问Redis服务。 那么问题是，我们本地测试无法直接连接 192.168.0.2:6543 ，这时候

本文讲述 vivo 官方商城从单体应用到具备综合能力电商平台的演进，系统架构往服务化、中台化的变迁历程。 一、前言 vivo官方商城，是vivo官方的线上电商平台，主营vivo手机及专属配件。经过几年发展，已经完成了从单体应用到具备综合能力电商平台的演进，整体系统架构也逐步往服务化、中台化变迁。我们在这条系统架构升级的道路中，实践出了一些系统架构经验。 通过本篇文章，可以让对电商感兴趣的小伙伴们，更为全面地了解最基础的电商业务模式，了解电商体系具备的技术和架构，了解系统在不同时期的架构演进。 二、架构变迁史 “冰冻三尺，非一日之寒”。任何一个电商系统的架构升级，都不是一蹴而就的，都需要一个稳步发展的过程，不同阶段业务发展的形态和体量决定着系统架构。下面从一张图开始，给大家描述下商城近几年架构变迁的历史。 （图1.1 vivo官方商城架构变迁历程） 2015年之前，vivo官方商城是外包项目，采用了市面上比较成熟的 ECStore （企业级开源网上电商系统）电商产品作为系统基础，主语言是PHP。 项目版本就是在此基础上进行二次开发迭代。 和大多数电商平台早期的发展一样，满足快速部署、快速上线。 同时弊端也很明显： 性能很差，根本无法支撑稍大一点的运营活动。当有新品、大促活动，系统负载高，业务基本处于不可用状态，无法满足运营活动需求。 需求沟通效率，研发效率低下，外包研发、产品异地办公

前言 雪花算法是用来在分布式场景下生成唯一ID的。 背景 雪花算法：雪花算法的原始版本是scala版，用于生成分布式ID（纯数字，时间顺序）,订单编号等。 自增ID：对于数据敏感场景不宜使用，且不适合于分布式场景。 GUID：采用无意义字符串，数据量增大时造成访问过慢，且不宜排序。 分布式系统中，有一些需要使用全局唯一ID的场景，这种时候为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。 有些时候我们希望能使用一种简单一些的ID，并且希望ID能够按照时间有序生成。 而twitter的snowflake解决了这种需求，最初Twitter把存储系统从MySQL迁移到Cassandra，因为Cassandra没有顺序ID生成机制，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统中不同机器产生的id必须不同，所以twitter开发了这样一套全局唯一ID生成服务。 叙述 算法详解 1位 ，不用。二进制中最高位为1的都是负数，但是我们生成的id一般都使用整数，所以这个最高位固定是0 41位 ，用来记录时间戳（毫秒）。 41位可以表示个数字， 如果只用来表示正整数（计算机中正数包含0），可以表示的数值范围是：0 至

1.背景： 因为公司变动，lz不得不出来看看机会， 面试的岗位主要是后端，历经三周，面了北京大大小小的几家公司，最后收获了满意的offer。 自己也成长收获了不少， 谨以笔记，自己可以日后回忆，也希望能帮助到最近寒冬下需要找工作的同学，在文章的后面会附上一点小心得和建议。 2.level 我是16年本科毕业， 算上实习接近2年半-3年的工作经历吧，一直做java后端。 自己定位大概能到p6+的水平。有大厂经验，本科211， 所以面试机会总体来说还是挺多的。 3.过程 大概是从元旦过后开始写简历，投简历，从7号开始陆陆续续面了若干公司， 有好有坏，以表格形式记录如下，以我面试的时间排序。 声明：虽然博客没有什么人看，但是如果您认为记录有不实或者伤害到下述公司名誉啥的， 直接联系我删除即可。 有朋友建议我省掉公司名，我就用某代替吧。 公司 部门 渠道 结果 感受（办公环境，面试难度，感受） 某信银行 DevOps Boss 4+0，拿到offer. （4技术面 0hr面，下同） 某信的位置和办公环境都很不错，位于安贞门。 面试官人很nice，没有多余的操作， 并且友好地帮我倒了一杯水。 主要针对简历中的项目，以及java基础进行面试。 难度也是循序渐进， 说实话因为是第一家面试， 我确实很多地方没有准备好，但是还是感谢面试官给我机会。 感受：之前感觉银行可能比较水，

当执行写操作后，需要保证从缓存读取到的数据与数据库中持久化的数据是一致的，因此需要对缓存进行更新。 因为涉及到数据库和缓存两步操作，难以保证更新的原子性。 在设计更新策略时，我们需要考虑多个方面的问题: 对系统吞吐量的影响：比如更新缓存策略产生的数据库负载小于删除缓存策略的负载 并发安全性：并发读写时某些异常操作顺序可能造成数据不一致，如缓存中长期保存过时数据 更新失败的影响：若某个操作失败，如何对业务影响降到最小 检测和修复故障的难度: 操作失败导致的错误会在日志留下详细的记录容易检测和修复。并发问题导致的数据错误没有明显的痕迹难以发现，且在流量高峰期更容易产生并发错误产生的业务风险较大。 更新缓存有两种方式: 删除失效缓存: 读取时会因为未命中缓存而从数据库中读取新的数据并更新到缓存中 更新缓存: 直接将新的数据写入缓存覆盖过期数据 更新缓存和更新数据库有两种顺序： 先数据库后缓存 先缓存后数据库 两两组合共有四种更新策略，现在我们逐一进行分析。 并发问题通常由于后开始的线程却先完成操作导致，我们把这种现象称为“抢跑”。 下面我们逐一分析四种策略中“抢跑”带来的错误。 先更新数据库，再删除缓存 若数据库更新成功，删除缓存操作失败，则此后读到的都是缓存中过期的数据，造成不一致问题。 可能发生的并发错误: 时间 线程A 线程B 数据库 缓存 1 缓存失效 v1 null 2

[TOC] 缓存 redis除了可以作为db存储用，还有一些场景是做二级缓存(比如mysql+redis或者mysql+memcached),所以这里总结下作为缓存时需要考虑的一些问题及解决方案 缓存穿透 名词解释：即黑客故意去请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。 解决方案: (一)利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试 (二)采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。 (三)提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回。 缓存雪崩(缓存失效) 名词解释：即缓存同一时间大面积的失效，这个时候又来了一波请求，结果请求都怼到数据库上，从而导致数据库连接异常。 解决方案: (一)给缓存的失效时间，加上一个随机值，避免集体失效。 (二)使用互斥锁，但是该方案吞吐量明显下降了。 (三)双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点 ● I 先从缓存A读数据