福建宁德建设局网站,erp系统排行榜,公司产品设计部门和销售,羽毛球赛事奖金typora-copy-images-to: imgs theme: cyanosis 敏感词库的设计#xff0c;要求增删改查敏感词。敏感词文本匹配#xff0c;敏感词一万个#xff0c;文本长度在 20 - 1000 答#xff1a;使用 trie 树来实现敏感词库的设计#xff0c;可以利用字符串公共前缀来节约存储空间。… typora-copy-images-to: imgs theme: cyanosis 敏感词库的设计要求增删改查敏感词。敏感词文本匹配敏感词一万个文本长度在 20 - 1000 答使用 trie 树来实现敏感词库的设计可以利用字符串公共前缀来节约存储空间。 生成 trie 树结构如下 1亿数据只有 1gb 内存怎么去重 答问题的本质是海量数据去重解决方案有两种 bitmap、布隆过滤器。 方案一bitmap 对于 1 亿的数据来说如果直接将所有数据读入内存使用 bitmap 来去重的话对每条数据使用 1 个 bit 标记是否存在即可1 亿 bit ≈ 12MB对于一条数据 a 来说会在 bitmap 中计算出他所放入的下标 x之后将 x 这个位置标记为1这样判断一个数据是否存在只占用 1 bit。 bitmap 方案适用场景 bitmap 适合值域较小的场景如果值域较大会导致计算出在 bitmap 数组中的下标过大比较占用存储空间适合数据密集场景对于数据稀疏场景比较浪费存储空间比如数据a下标为0但是数据b下标为1000000两个数据中间并没有数据但是却需要占用存储空间。 方案二布隆过滤器 当值域较大的情况下可以使用布隆过滤器进一步压缩 bitmap 的存储空间。 在布隆过滤器中对一个数据a布隆过滤器会使用 k 个哈希函数计算出 k 个哈希值在 bitmap 中将这 k 个位置都标记为1来表示这个数据存在。 布隆过滤器适用场景 适用于不严格去重的场景因为布隆过滤器的特性会导致存在误判率当判断为true时该数据可能在集合中当判断为 false 时该数据一定不在集合中。Java中可以使用第三方库来实现布隆过滤器常见的有Google Guava库和Apache Commons库以及Redis。 项目的登陆密码怎么存储用的什么加密算法为什么用 MD5 答项目登陆密码都会通过 MD5 加盐 操作对明文密码加密存储在数据库中。 MD5 会对每一个铭文密码生成一个对应的固定密码虽然 MD5 不可逆但是可以被暴力枚举出来所以在 MD5 的基础上还会添加加盐操作通过在密码任意固定位置插入特定的字符串让散列后的结果和使用原始密码的散列结果不相符。 订单到期后如何关闭订单 答参考文章https://mp.weixin.qq.com/s/BG1PqUWX0XwJX6aMCXCgvw 方案一定时任务定时去扫描所有到期的订单然后执行关单的动作。 缺点 时间不精确可能订单已经到了超时时间但是还没有到定时任务执行时间导致订单关闭时间比超时时间晚。无法处理大订单量如果订单量较大会导致定时任务执行时间很长导致后边订单被扫描到的时间很晚。对数据库造成压力定时任务集中扫描表会大量占用数据库io可以将定时任务将其他正常业务做好隔离分库分表问题订单系统在订单量大时会分库分表在分库分表中进行全表扫描很不推荐 适用场景 对过期时间精度要求不高业务量不大的场景 方案二JDK自带的延迟队列DelayQueue在用户创建订单时把订单加到 DelayQueue 中此外还需要一个常驻任务不断从队列读取已经超时的订单并进行关闭之后再将该订单从队列中删除。 该方案需要有一个线程添加 while(true) 循环才能确保任务不断执行并及时取出超时订单。 缺点 该方案是基于 JVM 内存的一旦机器重启会导致数据消失虽然可以配合数据库的持久化一起使用但是应用一般都是集群部署集群中的多台实例的 DelayQueue 如何配合也是一个很大的问题。当订单量过大时可能会导致 OOM 的问题。 适用场景 单机订单量不大 方案三RockerMQ延迟消息在订单创建好之后发送一个延迟消息指定延迟时间在延迟时间到达之后消息就会被消费者消费。 缺点 RocketMQ的延迟时间不支持任意的只支持1s、5s、10s、30s1m、2m等等商业版支持任意时长 适用场景RocketMQ支持延迟时间和我们所需延迟时间正好符合 方案四RabbitMQ插件基于 rabbitmq_delayed_message_exchange 插件该插件从 RabbitMQ 的 3.6.12 版本开始支持该插件为官方开发的。 在 RabbitMQ 中我们设置一个消息并且不去消费他当过了存活时间之后这个消息会变成死信会被发送到死信队列中。 在该插件中消息并不会立即进入队列而是先将他们保存到一个基于 Erlang 开发的 Mnesia 数据库再通过一个定时器去查询需要被投递的消息再投递到 x-delayed-message 队列中。 适用场景基于 RabbitMQ 插件的方式实现延迟消息最大延长时间大概为 49 天超过时间会被立即消费。可用性性能都不错。 方案五Redis 过期监听监听 key 的过期消息在接收到过期消息之后进行订单的关单操作。 缺点 Redis 不保证 key 在过期时会被立即删除也不保证消息能立即发出因此存在消息延迟在 Redis5.0 之前这个消息是通过 PUB/SUB 模式发出的不会进行持久化如果发送消息时客户端挂了之后再恢复的话这个消息就会彻底丢失。 方案六Redis 的 zset zset 是一个有序集合每一个元素关联一个 score通过 score 来对集合中的元素进行排序 我们可以将下单时间 超时时间 与订单号分别设置为 score 和 元素值通过 redis 进行排序之后再开启 redis 扫描任务获取 “当前时间 score” 的任务扫描到之后取出订单号进行关单操作。 优点使用 redis zset 可以借助 redis 的持久化、高可用机制避免数据丢失。在高并发场景中可能多个消费者同时获取同一个订单号一般采用分布式锁进行解决也可以做幂等性多个消费者获取同一个订单号也不影响进行处理。 # 命令示例 # 添加两个元素 a、b 分数为 10、25 127.0.0.1:6379 zadd delay_queue 10 a (integer) 1 127.0.0.1:6379 zadd delay_queue 25 b (integer) 1 # 查询分数为 9-12 的元素 127.0.0.1:6379 zrangebyscore delay_queue 9 12 limit 0 1 1) a方案七RedissionRedission 中定义了分布式延迟队列 RDelayedQueue即在 zset 基础上增加了一个基于内存的延迟队列当我们添加一个元素到延迟队列时redission 会把 数据超时时间 放到 zset 中并且启动一个延时任务当任务到期时再去 zset 中把数据取出来进行消费允许以指定的延迟时长将元素放到目标队列中。 优点可以解决方案六中的并发问题稳定性性能较高 方案八RocketMQ时间轮https://mp.weixin.qq.com/s/I91QRel-7CraP7zCRh0ISw 总体来讲Redission Redis、RabbitMQ插件、Redis的zset、RocketMQ延迟消息这几种方案比较推荐 一个系统用户登陆信息保存在服务器A上服务器B如何获取到Session信息分布式 Session 共享的解决方案 答将 Session 数据存储到分布式缓存比如 Redis 中所有的服务器都可以访问。 优点性能优秀、支持横向扩展Redis集群缺点存在数据丢失风险虽然 Redis 支持数据持久化但仍可能丢失小部分数据 如果让你来评估项目的QPS的话你会用什么方式来评估?(补充: 不要做压测就通过现在的设计以及硬件配置推导OPS应该达到什么水准?) 答首先需要根据业务提供的推广规模、渠道、人数来评估。这里根据 28 原则进行评估即 80% 的请求访问在 20% 时间内到达。 假如系统有1000万用户那么每天来点击页面的占比20%也就是200万用户访问。 假设平均每个用户点击50次那么总用有1亿的PV页面浏览量 一天24个小时平均活跃时间段算在5个小时内【24*20%】那么5个小时预计有8000万点击也就是平均每秒4500个请求。 4500是一个均值按照电商类峰值的话一般是3~4倍均值量也就是5个小时每秒18000个请求【QPS1.8万】