@purensong 变通一下你也得会答啊. 大方向可以说一下,从字节码的结构,语法要求说个大概,然后说具体的要参照 JVM 实现规范. Java 和 Kotlin 这些有啥关系. 常见的除了 Oracle 的还有哪些 JVM 实现等等. 说你记得起来的东西就行了.

你现在去了以后还是会考虑出来... 那本来就不是一个宜居的地方

点进来了发现没有鸭可以玩..

想搞云服务相关的东西现在是必须得学 Golang 了

你平时有空不想着看书提高技术吗? 天天 CRUD 确实到了 35 找工作困难

有已有的 Tomcat 或者其他 servlet 容器,用 war. 否则用 jar. 就是打包方式有点不一样,没啥本质区别.

@picone 官网上的建议是一个大的 hashmap 分成小的.. 而不是改成 string.

redis.io 官网上你全部看一遍再说吧

年轻人,40 岁以下的,身体健康,没遗传病的人,你能做的常规体检就那么多. 别做什么基因筛查,癌筛查的.

去普通公立医院挂个最便宜的号,说身体不舒服想体检,让医生给你开, 三大常规肝功 B 超 X 光血脂尿酸 耳鼻喉, 基本就这些. 可以走医保卡. 你自己去私立,一是不靠谱,二是有推销,三是不走医保. 没必要.

@EscYezi 可以跨可用区部署 redis 集群.

@blessingsi 想了一下,你说的对,是我理解错了..

@blessingsi 你可以从每天的零点开始算起，节省一些

忘了说,上面的说放到 hash 里,然后把里面的值进行位运算的话,要 evalsha 或者写 lua 脚本.

@yangbin9317

我们可以来计算一下 Redis 内存占用. 比如说限制 1 分钟 10 次.

我们可以算一下内存如果用 Redis 链表储存,假设是电商秒杀.网站有一亿个用户, 网站一分钟内会有 20%的用户参加秒杀.也就是两千万用户,那么所占用的内存(64 位机器)是 2000W * (48+ 24) byte = 21.5GB (一个 Node 占用 3 个 byte,不是 2 个.因为除了前后指针还有一个存值)

可见这样还是很耗内存的. 不过实际上,对于这样很小的 list,redis 用的是 skiplist 储存的,占用内存空间小很多. list-max-ziplist-size 这个参数可以调多少个元素以下用 ziplist 储存. 那么会用类似数组的形式储存. 具体占用多少我也不知道,得实际测一下了.

还有需要注意的就是,ZREMRANGEBYSCORE 命令的是 O(log(N)+M) 的复杂度,ZADD 是 O(logN) .


不过我我想到一个更好的方法:

把当前的毫秒 Unix 时间戳减去 2020 年得到一个比较小的数 a 代表当前时间, 每个用户分配一个 redis 的 String. 用户进来一次,就用 SETBIT 命令把这个 String 的数 a 位置上的 bit 设置为 1. 然后用 BITCOUNT 统计 当前时间戳减去时间区间 到 当前时间戳内 的范围内的为 1 的数目,就是用户这个时间段内的访问次数. 那么一个用户就占用 8 个 byte 的时间戳 + 90byte 的 redis string 的占用空间=98byte.

两千万用户就是 1.8GB 的内存占用

(当然,这里假设用户一毫秒最多访问一次,如果还要精确,可以换成 nano second.)



其实还可以更省:

那就是把用户的时间戳都放到一个 hash 里 (或者按照用户 id 取模分成 n 个小的 hash)

这样的话,2000W 用户占用的空间大概是 15 个 byte * 2000W= 280MB

还想再缩的话,换成 32bit 的 redis,应该可以到 200MB 以下..

@xuanbg

有. 如果要求 60 秒内访问 10 次. 你 key 60 秒过期一次. 那么我可以在 59 秒的节点访问十次,60 秒节点的时候你过期 key 了,数量清零. 61 秒的时候我又可以访问 10 次.

也就是说短短两秒的时间,我访问了 20 次. 这种情况要考虑到. 最坏情况就是访问到要求上限的两倍次数.

看一下我这个设计怎么样:

假设 60 秒内允许访问 10 次

那么 redis 里插入一个 USER_ID_LIST, 里面存 10 个当前的时间戳

每次用户进来,调用 RPOPLPUSH 这个命令,会在 list 右边插入当前时间,左边返回一个时间.

当左边返回的返回小于当前时间戳减去 60 秒的时候,说明已经触发机制. 这时候禁止用户操作.


RPOPLPUSH 这个命令是 O(1)的

正常情况不用担心机器同步时间的问题,大部分情况也不会超过 1 秒吧. 除非是对精度要求很高,可以用 Lua 脚本返回服务端的时间.

故意劣化访问质量,为全面墙做准备. 当初 Gmail 就是.