摘要：
第四篇打算作为系列最后一篇，这里尝试谈谈缓存的一些并发交互场景，包括与数据库（特指 RDBMS）交互，和一些独立的高并发场景相关补充处理方案（若涉及具体应用同样将主要以Redis举例）。 另见：分布式系统之缓存的微观应用经验谈（三）（数据分片和集群篇） （https://yq.aliyun.com/u/autumnbing） （https://www.cnblogs.com/bsfz/） 一、简单谈下缓存和数据库的交互流程 为了便于后面的相关讨论，这里约定文中的数据库（Database）均指传统的 RDBMS，使用DB标识，同时需区别于缓存（Cache）里的DB划分空间。 我在早前一篇缓存设计细节的文章里，有阐述关于 Cache 自身 CURD 时的一些具体细节，而这里将结合DB，就 DB 和 Cache 之间的并行 CURD 操作进行一些讨论。当然，这里面在交互层面上是一定会涉及到分布式事务（Distributed Transaction）相关的一致性话题，但为了避免表述出现模糊和不必要的边界放大，这里我尽可能剥离开来 阅读全文
摘要：
第三篇这里尝试谈谈缓存的数据分片（Sharding）以及集群（Cluster）相关方案（具体应用依然以Redis 举例）另见：分布式系统之缓存的微观应用经验谈（二） 【主从和主备高可用篇】（ https://www.cnblogs.com/bsfz/）
一、先分析缓存数据的分片（Sharding）
缓存在很多时候同 RDBMS类似，解决数据的分布式存储的基础理念就是把整个数据集按照一定的规则（切分算法）映射到多个节点（node）中，每个 node负责处理整体数据的一个子集。给缓存作 Sharding 设计，围绕基础数据的存储、通信、数据复制和整合查询等，很多时候比较类似 RDBMS中的水平分区（Horizontal Partitioning），事实上很多点在底层原理上是保持一致的。在缓存的分区策略中，最常见的是基于哈希的各种算法。 阅读全文
摘要：
第二篇这里尝试聊聊缓存的主从（Master-Slave），以及相关的高可用实现（High-Availability）（具体应用依然以Redis 举例）
1.1 关于主从分离的取舍观点
是否采用主从分离（这里特指读写分离），个人目前的观点是，它在很多场景里，并不是一个很好的方案。
我更想说的是，甚至任何涉及数据同步的环节，包括DB读写分离、缓存数据复制等等，如果没有特殊场景强制要求，那么尽量规避。
虽然在互联网的一些应用场景里，读远大于写，也演变了一套看似完整的读写实践方案，大体归为“主写从读”、“一写多读”、“多读多写”。但本质上，在大多数环境下，均存在一定缺陷，无论是基于服务底层的数据同步延迟，还是开发中的逻辑切换，都带来了一些可能本末倒置的隐患和生硬。同时，在集群模式下读写分离成本实在过高，不仅仅是一致性问题，必须慎重考虑和权衡。 阅读全文
摘要：
这是个人的一篇无关技术的小日记（仅作暂存） Everyone has his inherent ability which is easily concealed by habits, blurred by time, and eroded by laziness. 前言 无关技术讨论（其他：https://www.cnblogs.com/bsfz/），仅做个人暂时留存。
Everyone has his inherent ability which is easily concealed by habits, blurred by time, and eroded by laziness.
正文 心血来潮，想随便写点什么（仅作暂存） 。 阅读全文
摘要：
前言
近几个月一直在忙些琐事，几乎年后都没怎么闲过。忙忙碌碌中就进入了2018年的秋天了，不得不感叹时间总是如白驹过隙，也不知道收获了什么和失去了什么。最近稍微休息，买了两本与技术无关的书，其一是Yann Martel 写的《The High Mountains of Portugal》（葡萄牙的高山），发现阅读此书是需要一些耐心的，对人生暗喻很深，也有足够的留白，有兴趣的朋友可以细品下。好了，下面回归正题，尝试写写工作中缓存技术相关的一些实战经验和思考。
正文
在分布式Web程序设计中，解决高并发以及内部解耦的关键技术离不开缓存和队列，而缓存角色类似计算机硬件中CPU的各级缓存。如今的业务规模稍大的互联网项目，即使在最初beta版的开发上，都会进行预留设计。但是在诸多应用场景里，也带来了某些高成本的技术问题，需要细致权衡。本系列主要围绕分布式系统中服务端缓存相关技术，也会结合朋友间的探讨提及自己的思考细节。文中若有不妥之处，恳请指正。
第一篇这里尝试尽可能详细的谈谈缓存自身的基础设计应用，以及相关的操作细节等（具体应用主要以Redis 举例）。 阅读全文
摘要：
【为了方便独立成文，原谅在内容排版上的一点点个人强迫症】
【本文内容由上一篇扩展论述（详见：商城系统下单库存管控系列杂记（一） http://www.cnblogs.com/bsfz/p/7801980.html）】
四、阐述关于并发环境中库存管控的一些案例问题，以及涉及到的相关技术实现细节
库存扣减，简单来说，就是在对应的存储器中（数据库或者持久缓存）将对应商品的数量减少。
数据库设计时，一般包含但不限于 商品主表，商品规格表，商品库存表，商品库存流水日志表等等。但这里为了方便后续阐述，将其简化为一张表——商品表（PT），该表仅包含两个字段——商品主键（id）和商品库存（qty ）。
依然以商品P举例，其主键为pid，那么就是在下单时，将历史库存S修改为 S -N。具体到SQL里，原始操作大概是这样（以SQL SERVER 举例）：
update PT set qty = (S - N) where id = pid ;
这是以前的最原始的操作方式，单粒度的看，也没什么大碍。然而，放在一个并发环境中，则立马暴露出诸多问题。
假定在同一时刻， 阅读全文
摘要：
前言
参与过几个中小型商城系统的开发，随着时间的增长，以及对系统的深入研究和测试，发现确实有很多值得推敲和商榷的地方（总有很多重要细节存在缺陷）。基于商城系统，无论规模大小，或者本身是否分布架构，个人觉得最核心的一环就是下单模块，而这里面更相关和棘手的一些设计和问题，大多时候都涉及库存系统。想想之前跟某人的交流，他一句“库存管控做得好，系统设计就成功了一半”，自己颇有认同。围绕这个点，结合目前经验和朋友间的交流（包括近来参阅其他文章提到的点），闲来做些整理记录，也许不太完整，但总归希望能有更多启发，自己往后也会重新揣摩。当然，文中若有不妥，欢迎指正。
正文
谈及”下单“，就立刻想起前年参与的一个基于微信的小型商城系统，里面下单这块本身谈不上复杂，大概可以这样描述提交过程：用户提交商品订单，系统核对用户提交的订单，校验商品（商品价格、优惠折扣、积分等），检测附属信息（地址运费等），一切Pass，操作库存（记录/预扣），生成订单及相关联的明细数据。此时下单Ok，那么后续则是等待用户的及时付款了。 阅读全文
摘要：
前言
最近几个旧项目里使用的图片编辑插件出现Bug， 经Review 后确定需要在其内外均做些改动，但是头疼的发现部分页面里的JavaScript 代码被冗余了NN次。部分新同事堆叠了大量的过程式的脚本块（几乎没有利用面向对象封装的概念-虽然面向对象也按需择时），改起来挺累（而且几个项目里各自不同）。本身插件问题已经解决，但是就代码这块儿，针对面向对象的抽离封装，反而想写些东西。虽然没有太多分享价值，自己也忘记不少，翻了下以前的各种代码草稿，还是想尽量做些相对完整的记录和分享。当然，文中若有不妥，欢迎指正。
正文
JavaScript 编程本身是不包含传统“类”的概念的，这是不同于我们偏后端的一些强类型对象语言的（例如Java、C#等），而我们往往会利用funciton、 prototype 等关键字来实现一个类似“类”的原型模型（当然也包括各种继承特性）。从而使得项目中的js更优美，更高效。（截至最新的ECMAScript6里也推出了更简单的标准实现，后面会有相关演示）
【所有Demo 均可直接在我的github上下载（地址：https://gith 阅读全文
摘要：
前言
自从不玩CSDN后，就两年没写博客了。目前打算用CNBLOG来重新写些分享，先尝试写写看。最近忙于新工作，公司是一家互联网创业公司，软件部门正处于部分调整和完善中，已经涉及到公司内部开发框架的新版设计和技术实现。原框架构建初期为了快速实现基础功能，底层设计上并不复杂，但后续没有管控的迭代，导致暴露问题较多（包括稳定、性能、以及灵活度），甚至设计思想层面上都存在明显局限（当然，这并不妨碍对初期相关人员的努力表示肯定）。个人目前的具体职能是软件研发（架构方向），这次将主要负责这一块的从零到一的整体设计和细节实现，这于本人也是一次新的挑战（涉及前后端较多技术点），包括后续也会作内部的技术培训和讨论。这段时间一直忙忙碌碌，稍得休息，想着把整体过程进行阶段性记录和交流分享。
谈及软件架构，无论你是看书，还是逛博客，会发现到处充斥着相关的专业名词，什么3Tier、工厂、MVC、MVP、MVVM、接口、TDD、DDD、CQRS、队列等等等。或是微观或是宏观，几乎每一个都有相关书籍的大篇幅介绍，你也能找到很多具体实现的开源项目去参考和借鉴。本人不会对这些去单独阐述个人的理解（当然能力也有 阅读全文