如何为网站部署微信手机版并提供题库功能？

网站建设 部署与发布题库,微信手机网站案例,产品推广的目的和意义,网站建设成本 网站空间事务 理论 可以一次执行多个命令#xff0c;本质是一组命令的集合。一个事务中的所有命令都会序列化#xff0c;按顺序地串行化执行而不会被其它命令插入#xff0c;不许加塞 一个队列中#xff0c;一次性、顺序性、排他性的执行一系列命令 Redis事务 VS 关系型数据库事务… 事务 理论 可以一次执行多个命令本质是一组命令的集合。一个事务中的所有命令都会序列化按顺序地串行化执行而不会被其它命令插入不许加塞 一个队列中一次性、顺序性、排他性的执行一系列命令 Redis事务 VS 关系型数据库事务  单独的隔离操作Redis的事务仅仅是保证事务里的操作会被连续独占的执行redis命令执行是单线程架构在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的没有隔离级别的概念事务提交前任何指令不会被执行因此不存在脏读、幻读等不保证原子性Redis的事务不保证原子性也就是不保证所有指令同时成功或同时失败只有决定是否开始执行全部指令的能力没有执行到一半进行回滚的能力排它性Redis会保证一个事务内的命令依次执行而不会被其它命令插入 命令 DISCARD取消事务放弃执行事务块内的所有命令。 DISCARD取消事务放弃执行事务块内的所有命令。 EXEC标记一个事务块的开始。 UNWATCH 取消 WATCH 命令对所有 key 的监视。 WATCH  监视一个(或多个) key 如果在事务执行之前这个(或这些) key 被其他命令所改动那么事务将被打断。 案例 正常放行 MULTI-指令集-EXEC 放弃事务 MULTI-指令集-DISCARD  全部连坐 一个队列中命令在写入队列时出现错误将直接影响队列整体的提交。 冤头债主 一个队列中命令在写入队列时未出现错误但在执行时出错。只影响错误指令的执行结果其他正常执行的指令结果没影响。 WATCH监控  Redis 使用watch提供乐观锁锁定类似CAS(CHECK-AND-SET) 悲观锁(Pessimistic Lock)每次去拿数据的时候都认为别人会修改所以每次在拿数据的时候都会上锁想拿这个数据就会block直到它拿到锁。乐观锁(Optimistic Lock)每次去拿数据的时候都认为别人不会修改所以不会上锁在更新 的时候会判断一下在此期间别人有没有去更新这个数据。乐观锁策略:提交版本必须 大于 记录当前版本才能执行更新CAS利用WATCH去监控key,EXEC时去验证是否被操作 初始化acount和balance两个key,先监控再开启multi保证两key变动在同一个事务内 未加塞  加塞  如果监控的balance事务开启后被其他客户端修改后当前客户端的事务失败。 UNWATCH 管道  面试题 如何优化频繁命令往来造成的性能瓶颈?         管道(pipeline)可以一次性发送多条命令给服务端服务端依次处理完完毕通过一次性将响应结果返回减少客户端与redis的通信次数来实现降低往返延时时间。         pipeline实现的原理是队列先进先出特性就保证数据的顺序性。  作用 Pipeline是为了解决RTT往返回时仅仅是将命令打包一次性发送对整个Redis的执行不造成其它任何影响。简言之批处理命令变种优化类似Redis的原生批处理命令mget/mset 案例  利用Linux的CAT命令特性返回结果集作为pipe的参数 总结 管道与原生批量命令对比原生批量命令是服务端实现的管道需要服务的与客户端共同完成原生批量命令一次只能执行一种命令管道支持批量执行不同命令原生命令是原子性如mset\mget,管道是非原子性的管道与事务对比事务具有原子性管道不具有原子性事务逐条发送到队列接收到exec命令后才执行管道一次性将多条命令发送到服务器执行事务时会阻塞其他命令执行管道中的命令不会阻塞使用管道注意事项管道缓冲的指令只会依次执行不保证原子性执行过程中发生异常会继续执行后续指令使用管道组装的命令个数不能太多数据量过大客户端阻塞的时间可能过久服务端也被迫回复一个队列答复占用很多内存 发布订阅 了解 理论 一种消息通信模式:发送者(PUBLISH)发送消息订阅者(SUBSCRIBE)接收消息可以实现进程间的消息传递 。 Redis可以实现消息中间件MQ的功能通过发布订阅实现消息的引导和分流。 代表我个人不推荐使用该功能专业的事情交给专业的中间件处理redis就做好分布式缓存功能 案例  先订阅再发布  SUBSCRIBE pattern [pattern ...]订阅一个或多个符答给定模式的频道。