场景应用

应用场景： ehcache是Hibernate中默认的CacheProvider，直接在jvm虚拟机中缓存，速度快，效率高；但是缓存共享麻烦，集群分布式应用不方便。 . 缓存数据有两级：内存和磁盘，因此无需担心容量问题，提供Hibernate的缓存实现 Ehcache 在 Java 项目广泛的使用。它是一个开源的、设计于提高在数据从RDBMS中取出来的高花费、高延迟采取的一种缓存方案。正因为Ehcache具有健壮性（基于java开发）、被认证（具有apache 2.0 license）、充满特色（稍后会详细介绍），所以被用于大型复杂分布式web application的各个节点中。 什么特色？ 1. 够快 Ehcache的发行有一段时长了，经过几年的努力和不计其数的性能 测试 ，Ehcache终被设计于large, high concurrency systems. 2. 够简单 开发者提供的接口非常简单明了，从Ehcache的搭建到运用运行仅仅需要的是你宝贵的几分钟。其实很多开发者都不知道自己用在用Ehcache，Ehcache被广泛的运用于其他的开源项目 比如： hibernate 3.够袖珍 关于这点的特性，官方给了一个很可爱的名字small foot print ，一般Ehcache的发布版本不会到2M，V 2.2.3 才 668KB。 4. 够轻量

转载 AI科技大本营 最后发布于2019-08-09 19:52:18 阅读数 195 收藏 展开 作者丨gongyouliu 来源 | 大数据与人工智能 导语：本文会从协同过滤思想简介、协同过滤算法原理介绍、离线协同过滤算法的工程实现、近实时协同过滤算法的工程实现、协同过滤算法应用场景、协同过滤算法的优缺点、协同过滤算法落地需要关注的几个问题等7个方面来讲述。希望读者读完本文，可以很好地理解协同过滤的思路、算法原理、工程实现方案，并且具备基于本文的思路自己独立实现一个在真实业务场景中可用的协同过滤推荐系统的能力。 作者在《 推荐系统产品与算法概述 》这篇文章中简单介绍了协同过滤算法。协同过滤算法是在整个推荐系统发展史上比较出名的算法，具备举足轻重的地位，甚至在当今还在大量使用。本篇文章作者会详细讲解协同过滤推荐算法的方方面面，这里所讲的也是作者基于多年推荐系统研究及工程实践经验的基础上总结而成，希望对大家学习协同过滤推荐算法有所帮助，提供一些借鉴。在正式讲解之前，先做一个简单定义。本文用“ 操作过” 这个词来表示用户对标的物的各种操作行为，包括浏览、点击、播放、收藏、评论、点赞、转发、评分等等。 一、协同过滤思想简介 协同过滤，从字面上理解，包括协同和过滤两个操作。所谓协同就是利用群体的行为来做决策(推荐)，生物上有协同进化的说法，通过协同的作用，让群体逐步进化到更佳的状态

性能优化简图 打造一个高质量的应用应该以4个方向为目标：快、稳、省、小。 快：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。 稳：减低 crash 率和 ANR 率，不要在用户使用过程中崩溃和无响应。 省：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。 小：安装包小可以降低用户的安装成本。 要想达到这4个目标，具体实现是在右边框里的问题：卡顿、内存使用不合理、代码质量差、代码逻辑乱、安装包过大，这些问题也是在开发过程中碰到最多的问题，在实现业务需求同时，也需要考虑到这点，多花时间去思考，如何避免功能完成后再来做优化，不然的话等功能实现后带来的维护成本会增加。 卡顿优化 Android 应用启动慢，使用时经常卡顿，是非常影响用户体验的，应该尽量避免出现。卡顿的场景有很多，按场景可以分为4类：UI 绘制、应用启动、页面跳转、事件响应，如图： 卡顿场景分析 这4种卡顿场景的根本原因可以分为两大类： 界面绘制。主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。 数据处理。导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。 引起卡顿的原因很多

官网文档地址： https://zookeeper.apache.org/doc/r3.5.4-beta/zookeeperOver.html 概述 Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架， 它负责存储和管理大家都关心的数据， 然后接受观察者的注册， 一旦这些数据的状态发生变化， Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应 ， 从而实现集群中类似Master/Slave管理模式。 Zookeeper 是一个分布式的服务框架，主要用来 解决分布式集群中应用系统的协调和一致性问题 ，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。如：统一命名服务、状态同步服务、集群管理、分布式应用配置管理等。 它能够为分布式应用提供高性能和可靠地协调服务，使用ZooKeeper可以大大简化分布式协调服务的实现，为开发分布式应用极大地降低了成本。协同服务很难正确运行，经常出现竞争危害和死锁。ZooKeeper 的目的就是降低协同服务实现与维护的成本。 架构及原理 集群架构 Zookeeper集群是由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点

随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用到的etcd组件作为一个 高可用、强一致性的服务发现存储仓库 ，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本文将从etcd的应用场景开始，深入解读etcd的实现方式，以供开发者们更为充分地享用etcd所带来的便利。 etcd 是一个高可用的 Key/Value 存储系统，主要用于分享配置和服务发现。etcd 的灵感来自于 ZooKeeper 和 Doozer，側重于： 简单 ：支持 curl 方式的用户 API (HTTP+JSON) 安全 ：可选 SSL client证书认证 高速 ：单实例可达每秒 1000 次写操作 可靠 ：使用 Raft 实现分布式 Etcd is written in Go and uses the raft consensus algorithm to manage a highly-available replicated log. 经典应用场景 要问etcd是什么？很多人第一反应可能是一个键值存储仓库，却没有重视官方定义的后半句，用于 配置共享和服务发现 。

我们从 2016 年开始在集团推广全面的镜像化容器化，今年是集团全面镜像化容器化后的第 4 个 双11，PouchContainer 容器技术已经成为集团所有在线应用运行的运行时底座和运维载体，每年 双11 都有超过百万的 PouchContainer 容器同时在线，提供电商和所有相关的在线应用平稳运行的载体，保障大促购物体验的顺滑。 我们通过 PouchContainer 容器运行时这一层标准构建了应用开发和基础设施团队的标准界面，每年应用都有新的需求、新的变化，同时基础设施也有上云/混部/神龙/存储计算分离/网络变革这些升级，两边平行演进，互不干扰。技术设施和 PouchContainer 自身都做了很大的架构演进，这些很多的架构和技术演进对应用开发者都是无感知的。 在容器技术加持的云原生形成趋势的今天，PouchContainer 容器技术支持的业务方也不再只有集团电商业务和在线业务了，我们通过标准化的演进，把所有定制功能做了插件化，适配了不同场景的需要。除了集团在线应用，还有运行在离线调度器上面的离线 job 类任务、跑在搜索调度器上面的搜索广告应用、跑在 SAE/CSE 上面的 Serverless 应用、专有云产品及公有云（ACK+CDN）等场景，都使用了 PouchContainer 提供的能力。 运行时的演进 2015 年之前，我们用的运行时是 LXC

Redis 几种数据类型及应用场景 Redis支持5种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。何时使用Redis呢? 先通过一张图了解下Redis内部内存管理中是如何描述这些不同数据类型的： 首先Redis内部使用一个redisObject对象来表示所有的key和value，redisObject最主要的信息如上图所示：type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int，如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:"123" "456"这样的字符串。   这里需要特殊说明一下vm字段，只有打开了Redis的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的。通过上图我们可以发现Redis使用redisObject来表示所有的key/value数据是比较浪费内存的，当然这些内存管理成本的付出主要也是为了给Redis不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用，我们随后会具体讨论。   一、string

Redis支持5种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。何时使用Redis呢? 先通过一张图了解下Redis内部内存管理中是如何描述这些不同数据类型的： 首先Redis内部使用一个redisObject对象来表示所有的key和value，redisObject最主要的信息如上图所示：type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int，如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:"123" "456"这样的字符串。   这里需要特殊说明一下vm字段，只有打开了Redis的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的。通过上图我们可以发现Redis使用redisObject来表示所有的key/value数据是比较浪费内存的，当然这些内存管理成本的付出主要也是为了给Redis不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用，我们随后会具体讨论。   一、string string 是 redis

标准Http协议支持6中请求方法，即： 　　0，GET 　　1，HEAD 　　2，PUT 　　3，DELETE 　　4，POST 　　5，OPTIONS 　　但其实我们大部分情况下只用到了GET和POST。如果想设计一个符合RESTful规范的web应用程序，则这六种方法都会用到。不过即使暂时不想设计REST，了解这六种方法的本质仍然很有作用的。下面一次说明这六种方法。 　　0，GET：GET可以说是最常见的了，它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。 　　1，HEAD：HEAD和GET本质是一样的，区别在于HEAD不含有呈现数据，而仅仅是HTTP头信息。有的人可能觉得这个方法没什么用，其实不是这样的。想象一个业务场景：欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则一样更加明确。 　　2，PUT：这个方法比较少见。HTML表单也不支持这个。本质上来讲，PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。举个例子：如一个用于提交博文的URL，/addBlog。如果用PUT，则提交的URL会是像这样的“/addBlog/abc123”

2.1 Activity 1.Activity是什么？ Activity是Android的四大组件之一。是用户操作的可视化界面；它为用户提供了一个完成操作指令的窗口。 当我们创建完毕Activity之后，需要调用setContentView()方法来完成界面的显示；以此来为用户提供交互的入口。 2.典型情况下的Activity生命周期？ Activity启动–>onCreate()–>onStart()–>onResume() 点击home键回到桌面–>onPause()–>onStop() 再次回到原Activity时–>onRestart()–>onStart()–>onResume() 退出当前Activity时–>onPause()–>onStop()–>onDestroy() 3.异常情况下的Activity的生命周期 & 数据如何保存和恢复？ 在onStop之前调用onSaveInstanceState保存当前Activity状态,当Activity被重新创建后,系统调用 onRestoreInstanceState，并且把Activity销毁时onSaveInstanceState方法所保存的Bundle对象 作为参数传递给onRestoreInstanceState和onCreate方法 onRestoreInstanceState的调用时机发生在onStart之后