hash

前言 这段时间面试官都挺忙的，频频出现在博客文章标题，虽然我不是特别想蹭热度，但是实在想不到好的标题了-。-，蹭蹭就蹭蹭 :) 事实上我在面试的时候确实被问到了这个问题，而且是一道在线 coding 的编程题，当时虽然思路正确，可惜最终也并不算完全答对 结束后花了一段时间整理了下思路，那么究竟该如何实现一个大文件上传，以及在上传中如何实现断点续传的功能呢？ 本文将从零搭建前端和服务端，实现一个大文件上传和断点续传的 demo 文章有误解的地方，欢迎指出，将在第一时间改正，有更好的实现方式希望留下你的评论 大文件上传 整体思路 前端 前端大文件上传网上的大部分文章已经给出了解决方案，核心是利用 Blob.prototype.slice 方法，和数组的 slice 方法相似，调用的 slice 方法可以返回原文件的某个切片 这样我们就可以根据预先设置好的切片最大数量将文件切分为一个个切片，然后借助 http 的可并发性，同时上传多个切片，这样从原本传一个大文件，变成了同时传多个小的文件切片，可以大大减少上传时间 另外由于是并发，传输到服务端的顺序可能会发生变化，所以我们还需要给每个切片记录顺序 服务端 服务端需要负责接受这些切片，并在接收到所有切片后合并切片 这里又引伸出两个问题 何时合并切片，即切片什么时候传输完成 如何合并切片 第一个问题需要前端进行配合

一、简介 上篇文章 详细介绍了HashMap的源码及原理，本文趁热打铁继续分析ConcurrentHashMap的原理。 首先在看本文之前，希望对HashMap有一个详细的了解。不然看直接看ConcurrentHashMap的源码还是有些费劲的。 相信对HashMap，HashTable有一定了解，应该知道HashMap是不具备线程安全性的，在resize时会丢数据（JDK8），而HashTable虽然保证了线程安全性，但是其是通过给每个方法加Synchronized关键字达到的同步目的。但是都知道Synchronized在竞争激烈的多线程并发环境中，在性能上的表现是非常不如人意的。那在高并发环境中HashMap如何保证线程安全而又不浪费太多性能呢？答案就是Java J.U.C并发包中的ConcurrentHashMap。 依然开局一张图。JDK8中的ConcurrentHashMap数据结构。 呃呵，和HashMap的结构是一样的，没错在数据结构层面，ConcurrentHashMap和HashMap是完全一样的。有了这个基础继续往下看。 二、历史版本 ConcurrentHashMap的历史版本大致分界线在JDK8。也就是可以分为JDK8和JDK8以前版本。 数据结构的区别 在JDK8之前HashMap没有引入红黑树，同样的ConcurrentHashMap也没有引入红黑树

概述 ConcurrentHashMap是JDK提供的一个线程安全的集合类，它内部的结构原理和我们常用的HashMap基本是一致，那我们可以先来认识一下HashMap，这样基本上也能大致明白ConcurrentHashMap了。 数据结构 HashMap与ConcurrentHashMap都是用来存放一种键值对形式的数据，那它们内部的数据结构是怎么样的呢？ 首先来看看HashMap的put方法 public V put(K key, V value) { // put方法中首先对key进行hash运算，再调用putVal return putVal(hash(key), key, value, false, true); } final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) { Node<K,V>[] tab; Node<K,V> p; int n, i; if ((tab = table) == null || (n = tab.length) == 0) n = (tab = resize()).length; if ((p = tab[i = (n - 1) & hash]) == null) tab[i] = newNode(hash, key, value, null

· Hash: 和整个项目的构建相关，只要项目文件有修改，整个项目构建的hash值就会更改 Chunkhash(JS文件): 和webpack打包的chunk有关，不同的entry会生成不同的chunkhash值 Contenthash(CSS文件):根据文件内容来定义hash，文件内容不变，则contenthash不变 图片的文件指纹设置使用[hash] 设置MiniCssExtratPlugin的filename,使用[contenthash] 如果不使用MiniCssExtratPlugin正常情况下我们使用了style-load或css-load则会把样式提取出来放入到header的style里面，并没有独立的文件，所以使用MiniCssExtratPlugin提取成独立的文件 plugins: [ new MiniCssExtractPlugin({ filename: `[name]_[contenthash:8].css` }) ] module.exports = { entry: { index: './src/index.js', search: './src/search.js' }, output: { path: path.join(__dirname, 'dist'), filename: '[name]_[chunkhash:8].js' //

redis 是什么? 是完全开源免费的，用c语言编写的，是一个单线程，高性能的（key/value）内存数据库，基于内存运行并支持持久化的nosql数据库 能干嘛？ 主要是用来做缓存，但不仅仅只能做缓存，比如：redis的计数器生成分布式唯一主键，redis实现分布式锁，队列，会话缓存。 去哪下？ 官网，也可以通过Linux yum直接下载安装 怎么玩？ 1.安装 2.redis数据类型（api操作） 3.redis配置文件解析 4.redis的持久化 5.redis的事务 6.redis的发布订阅 7.java客户端操作（jedis） redis的安装 1.解压 2.make 如果make报错的话 大家就可以看一下是不是报没有gcc的错 如果是报没有gcc的错，那就要先安装一个gcc yum install gcc-c++ 安装好gcc之后最好执行一下make distclean 因为前面make的时候它执行了一些东西 要先把他清掉 3.make install 查看redis默认安装位置 /usr/local/bin redis设置外网访问 1.注释bind并且把protected-mode no 2.使用bind 3.设置密码 protected-mode它启用的条件有两个，第一是没有使用bind，第二是没有设置访问密码。 redis数据类型及api操作(http:/

注意点:无论按哪个纬度分表，订单号需要全局唯一，且需要包含库id和表id，以便定位。或者建一张订单号与分表纬度之间的关联表，并加载到缓存中。 此处以餐饮系统为例：按shopid分表 水平分表分库的方式一般有三种： 按范围分表，比如：shopid在1到1w的放在0表，shopid在1w1到2w的放在表1 优点：易于扩展 缺点：数据分散不均匀，容易出现单表瓶颈 hash分表（硬hash），比如： 库名称定位：用户id末尾4位 Mod 32。 Mod表示除以一个数后，取余下的数。比如除以32后，余下8，余数就是8。 代码符号是用%表示：15%4=3。 表名称定位：（用户id末尾4位 Dev 32） Mod 32。 Dev表示除以一个数，取结果的整数。比如得到结果是25.6，取整就是25。 代码用/来表示：$get_int = floor(15/4)。15除以4，是一个小数3.75，向下取整就是3。一定是向下取整，向上取整就变成了4了。 优点：数据分散均匀 缺点：不易扩展，扩展需要做数据迁移。 一致性hash 特点：hash环、虚拟节点 这种情况是指销售平台上既有分买家又分买家 既需要根据userid查也需要根据shopid查 建冗余表，按用户id分表，再通过中间件异步按买家id分表。 原因：满足两个纬度的查询要求 来源： CSDN 作者： qq_16399457 链接： https:/