Redis

不点蓝字，我们哪来故事？ 游记： 游记是用户自己发表的。由用户自己管理，管理人员只负责审核和发布； 需求：查看和拒绝 用户的文章由前端用户自己维护，管理仅仅显示和对状态进行管理，不能进行添加编辑操作； 查看是前台只需要游记的内容即可，后台将游记的内容反给前台。根据当前游记的id查到游记对象，在从游记对象中 getContent() 返回即可； 审核状态： 审核逻辑 ：游记满足什么条件才进行审核，审核通过和审核不通过分别需要做什么操作？ 审核通过是发布状态； 只对状态是待审核的游记才进行审核； 审核通过/拒绝将游记的状态改成审核通过/审核拒绝； 审核通过之后还需要改变游记的发布时间和最后修改时间； 用户修改内容之后，需要考虑那些统计数据（点赞阅读等）要不要清空（问你的产品经理）； //审核游记 @ Override public void changeState ( String id, int state ) throws LoadException { //满足什么条件才进行审核 //查询游记 Optional<Travel> optional = repository.findById(id); if (!optional.isPresent() && state != Travel.STATE_WAITING) { //有内容并且状态是待审核的才审核,否则抛异常 throw

大型网站，比如门户网站，在面对大量用户访问、高并发请求方面带来的问题 1大并发：在同一个时间点，有大量的客户来访问我们的网站，如果访问量过大，就可能造成网站瘫痪。 2大流量：当网站大后，有大量的图片，视频, 这样就会对流量要求高，需要更多更大的带宽。 3大存储：你的数据量会成海量的数据，如果我们的数据放入一张表，是无法应对的。可能对数据保存和查询出现问题。 基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器，(对架构分层+负载均衡+集群)这几个解决思路在一定程度上意味着更大的投入。 解决方案： 一、提高硬件能力、增加系统服务器。（当服务器增加到某个程度的时候系统所能提供的并发访问量几乎不变，所以不能根本解决问题） 二、使用缓存（本地缓存：本地可以使用JDK自带的 Map、Guava Cache.分布式缓存：Redis、Memcache.本地缓存不适用于提高系统并发量，一般是用处用在程序中。比如Spring是如何实现单例的呢？大家如果看过源码的话，应该知道，Spiring把已经初始过的变量放在一个Map中，下次再要使用这个变量的时候，先判断Map中有没有，这也就是系统中常见的单例模式的实现。） 分布式缓存利器Redis集群，Redis集群的搭建至少需要三主三从。 1. 所有的redis节点彼此互联(PING-PONG机制)

一、问题 　从 Redis 中取出的 hvals 值排序是随机的（参看： https://github.com/phpredis/phpredis#hvals The order is random and corresponds to redis' own internal representation of the set structure.），导致前端显示与从数据库取出的值不一致，所以把hvals的值进行降序。 二、方法 　　主要用到PHP的 array_multisort — 对多个数组或多维数组进行排序 $unread_notify = $this ->redis->hvals(' ushark :unread:notify:3' ); foreach ( $unread_notify as & $val ) { $val = json_decode( $val , true ); } $time = array_column( $unread_notify , 'newest_time' ); array_multisort ( $time , SORT_DESC, $unread_notify ); !!! 关键 !!! print_r ( $unread_notify ); 来源： oschina 链接： https://my.oschina.net/u

Codis 详细介绍 Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务. Codis 由四部分组成: Codis Proxy (codis-proxy) Codis Manager (codis-config) Codis Redis (codis-server) ZooKeeper codis-proxy 是客户端连接的 Redis 代理服务, codis-proxy 本身实现了 Redis 协议, 表现得和一个原生的 Redis 没什么区别 (就像 Twemproxy ), 对于一个业务来说, 可以部署多个 codis-proxy, codis-proxy 本身是无状态的. codis-config 是 Codis 的管理工具, 支持包括, 添加/删除 Redis 节点, 添加/删除 Proxy 节点, 发起数据迁移等操作. codis-config 本身还自带了一个 http server, 会启动一个

这边文章主要实战如何使用Mybatis以及整合Redis缓存，数据第一次读取从数据库，后续的访问则从缓存中读取数据。 1.0 Mybatis MyBatis 是支持定制化 SQL、存储过程以及高级映射的优秀的持久层框架。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以对配置和原生Map使用简单的 XML 或注解，将接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录。 MyBatis并不是一套完整的ORM数据库连接框架，目前大多数互联网公司首选的数据库连接方式，不会对应用程序或者数据库的现有设计强加任何影响。 SQL写在xml里，便于统一管理和优化。解除SQL与程序代码的耦合：通过提供DAL层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。SQL和代码的分离，提高了可维护性。 它的优点也正是缺点，编写SQL语句时工作量很大，尤其是字段多、关联表多时，更是如此。 SQL语句依赖于数据库，导致数据库移植性差，不能更换数据库。 1.1使用 MyBatis 官方提供的 Spring Boot 整合包实现。 1.1.1. pom.xml里面添加mybatis jar包。 <!-- springboot,mybatis 整合包 --> <

前言 在调试网络程序或者定位网络相关问题时，有一个命令不得不知，它就是netstat。netstat命令用于查看网络连接，路由表，网络接口统计数据, 虚拟连接等信息。netstat的选项很多，但是本文准备介绍一些netstat命令的实用技巧。 查看某个端口是否被占用 如果你遇到“Address already in use”的错误，那么你就需要好好看看是不是端口已经被占用了。-a（all）参数用于列出所有监听和非监听状态的连接。 $ netstat -a|grep 6379 tcp 0 0 *:6379 *:* LISTEN tcp6 0 0 [::]:6379 [::]:* LISTEN 这里我们可以看到，有一个tcp连接使用了6379端口，并且当前处于LISTEN状态，这些状态信息对于分析网络连接问题非常有帮助，我们将会在后面的文章中看到它们大放异彩。 当然你也可以使用lsof命令中的方法来查看。 查找占用端口的进程 前面虽然知道已经有进程使用了6379端口，但是不知道是哪个进程，因此为了知道进程信息，需要使用-p(program)参数： $ netstat -ap|grep 6379 tcp 0 0 *:6379 *:* LISTEN 10011/redis-server tcp6 0 0 [::]:6379 [::]:* LISTEN 10011/redis-server

单体架构（all in one） 所有模块都在一起，技术也不分层。 在单机上部署所有的应用程序和软件。 所有的代码都写在JSP里面，所有代码都写在一起，这种方式称为all in one。 特点： 1.不具备代码的可维护性。 2.容错性差。（容错性是指软件检测应用程序所运行的软件和硬件中发生的错误并从错误中恢复的能力，可以从系统的可靠性，可用性，可测性等几个方面衡量） 因为所有代码都写在JSP页面里，当因为用户或某些原因发生异常时：用户可以直接看到异常错误信息；异常会导致服务器宕机。 单体地狱： 只需一个应用，将所有功能部署在一起，以减少部署节点和成本。 解决方案 1.分层开发：解决单体架构容错性差的问题，同时提高了代码的维护性。 2.MVC架构（Web应用程序的设计模式） 3.服务器的部署分离。 特点： 1.MVC分层开发：解决容错性问题。 2.数据库和项目部署分离。 <font color=red>问题</font>： 1.高并发：随着用户访问量的持续增加，单台服务器无法满足用户访问需求。 解决方案： 1.集群 集群操作可能遇到的问题 高可用 高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。 如何保证高可用：避免单点。 高并发 高并发

背景：最近美团在招聘，打算好好准备准备简历，然后投递一波。 美团点评 社招 一面（3.6中午）结果通过 美女面试官 1 HashMap的put怎么实现，如何解决hash冲突。 调用putval，计算相应hash码，然后初始化（默认64的capacity）或调用resize函数调整大小，判断bucket是否有值，若没有在数组初始化改值。若有则以拉链法（链表的形式）解决hash冲突，这里和ThreadLocalMap不一样，ThreadLocalMap使用的是线性探测法，接着将相应节点加入链表头部。如果超过8个元素会进化为RBtree，防止hash攻击。 RBtree是怎样的数据结构，有什么性质？ 二叉树，有序的，四种性质。从而推得路径最长2n，最短n。复杂度为log2N.（此处省略n多话，感兴趣的同学请自行Google） RBtree什么时候会变色？ 旋转时，共有四种旋转方式。一般是为了保持平衡，如左边太长，右边太短这样。（打哈哈过去，具体记不清了） hashmap什么时候会调整大小？ 根据负载因子来搞事，默认为0.75。 什么是负载因子？ 根据capacity来，举个例子，当capacity为100时，如果HashMap的ele的数量到了75就会resize，resize后的大小为原来的2倍，这样可以直接使用位运算得到原来的元素新的hash值。 扩容存在什么问题？ （楞了一会