Designing Data Intensive Applications 读书笔记

-

 > Designing Data Intensive Applications 


Location: 美国加利福尼亚

Comments

Post a Comment

Popular posts from this blog

库存优化专题

-
markdown # 库存优化专题 - 开放平台技术部 ## this is T2 ``` 空间 人员 创建 创建 快速搜索  帮助 各空间管理员信息  E编辑 F收藏 观看 S分享 页面/…/ 性能优化专题 跳到banner的尾部  回到标题开始 库存优化专题 转至元数据结尾 由 创建, 最后修改于十月 12, 2019 转至元数据起始 背景 名词解释 整体思路 表结构设计 冻结库存调整 开启热点商品 关闭热点商品 归还库存 参考 背景 目前交易下单流程中，主要有下订单、冻结优惠券、冻结库存操作，其中冻结库存由于受限于单行行锁的原因，只能支持极限 600 TPS。 在可预见的未来，冻结库存将会成为下单流程中的瓶颈，所以承需解决库存性能瓶颈，提高整体下单的 TPS，保障未来业务的稳定高速发展 名词解释 下单过程中库存主要以商品 sku 维度来进行冻结 普通商品：下单扣库存并发不高的商品 秒杀商品：库存比较少，下单扣库存并发高的商品 热点商品：库存比较多，下单扣库存并发高的商品（库存超过 1W 以上） 秒杀商品与热点商品区别在于秒杀商品很快就会将库存扣减为0，且之后就不会再有扣库存请求了，没有必要进行热点分片。所以，下文讨论主要讨论热点商品。 整体思路 冻结库存主要分为两步 ：插入幂等日志和冻结 sku 库存。其中性能单点就是下面冻结 sku 库存 update 语句，由于同时更新一条记录，受限于 MySQL 行锁，只能支持 600 TPS 。 1. 开启事务 start transaction 2. 插入幂等操作日志 insert stock_log 3. 冻结 sku 库存 update sku_item set frozen_stock = frozen_stock + 1, available_stock = available_stock -1 where available_stock > 0 4. 关闭事务 end transaction 针对 update 瓶颈其实为 I/O瓶颈，解决方法主要两种： 增加 IO 设备 （分散读写记录） 减少 IO 次数（批量一次性提交） 在热点商品场景下，初步思路采用水平拆分分片的思路来分散热点数据。原先单条 sku 记录拆分成主 sku 记录(sku_item...
Read more

90.subsets-ii

-
  /* * @lc app=leetcode id=90 lang=java * * [90] Subsets II * * https://leetcode.com/problems/subsets-ii/description/ * * algorithms * Medium (56.68%) * Likes: 9237 * Dislikes: 265 * Total Accepted: 819.4K * Total Submissions: 1.4M * Testcase Example: '[1,2,2]' * * Given an integer array nums that may contain duplicates, return all possible * subsets (the power set). * * The solution set must not contain duplicate subsets. Return the solution in * any order. * * * Example 1: * Input: nums = [1,2,2] * Output: [[],[1],[1,2],[1,2,2],[2],[2,2]] * Example 2: * Input: nums = [0] * Output: [[],[0]] * * * Constraints: * * * 1 <= nums.length <= 10 * -10 <= nums[i] <= 10 * * * * 思路：使用回溯算法, 对unique数组的全排列的变种 * 问题拆分成 从n个元素的数组中选者k个元素的素全组合 * , 再收集所有子组合时去重即可 * */ // @lc code=start import java . util . ArrayList ; import java . util . List ; class Solution { public List < List < Integer >> subsetsWithDup...
Read more

String、StringBuffer和StringBuilder的区别

-
概念： 1、用来处理字符串常用的类有3种：String、StringBuffer和StringBuilder 2、三者之间的区别： 都是final类，都不允许被继承； String类长度是不可变的，StringBuffer和StringBuilder类长度是可以改变的； StringBuffer类是线程安全的，StringBuilder不是线程安全的； String 和 StringBuffer： 1、String类型和StringBuffer类型的主要性能区别：String是不可变的对象，因此每次在对String类进行改变的时候都会生成一个新的string对象，然后将指针指向新的string对象，所以经常要改变字符串长度的话不要使用string，因为每次生成对象都会对系统性能产生影响，特别是当内存中引用的对象多了以后，JVM的GC就会开始工作，性能就会降低； 2、使用StringBuffer类时，每次都会对StringBuffer对象本身进行操作，而不是生成新的对象并改变对象引用，所以多数情况下推荐使用StringBuffer，特别是字符串对象经常要改变的情况； 3、在某些情况下，String对象的字符串拼接其实是被Java Compiler编译成了StringBuffer对象的拼接，所以这些时候String对象的速度并不会比StringBuffer对象慢，例如： String s1 = “This is only a” + “ simple” + “ test”; StringBuffer Sb = new StringBuilder(“This is only a”).append(“ simple”).append(“ test”); 生成 String s1对象的速度并不比 StringBuffer慢。其实在Java Compiler里，自动做了如下转换： Java Compiler直接把上述第一条语句编译为： String s2 = “This is only a”; String s3 = “ simple”; String s4 = “ test”; String s1 = s2 + s3 + s4; 这时候，Java Compiler会规规矩矩的按照原来的方式去做，String的concatenation（即+）操作利用了Stri...
Read more