工作中心得记录20151015

╰+哭是因爲堅強的太久メ 2022-08-09 06:56 167阅读 0赞

1.学会看eclipse中的用mvn管理的项目的pom文件

2.[CMD开启快速编辑模式][CMD]

3.浏览器在打开网页时要咋新建标签页打开，按住ctrl 在点击链接

4.JVM的内存和电脑的内存区别? 答：本质上没区别，只是在在电脑上开一个进程，这个进程有自己管理的内存。（JVM内存是从电脑内存里面申请出来的。 ）一个JVM实例占用一块内存（物理）区域，然后JVM将自己管理这一块内存（这时这块内存就属于这个JVM了），这是内存的分配，就有JVM来控制，无论你是堆，还是栈，还是代码段，数据段，都逃不出这一块内存区域了。不知道我这样的理解是否正确

5. 在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。 Redis只会缓存所有的 key的信息 ，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age\*log(size\_in\_memory)”计 算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以 保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能  
　　Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS  
　　进行枚举操作

6.java中Thread t=new Thread(new Runnable()\{\});这是怎么回事？接口还能这么玩？你问的同等与这种写法，实例化了一个Runnable接口子类的实例  
Thread t=new Thread(new MyRunnable());  
public class MyRunnable implements Runnable\{  
@Override  
public void run() \{  
//具体实现  
\}  
\}

7.分布式： Distributed是针对用户/终端来讲的，把Job送到地理上分散的sever(i.e. 网格类)上协同作业，然后合并计算结果 分布式是解决高性能、高并发的  
一个业务分拆多个子业务，部署在不同的服务器上  
集群：同一个业务，部署在多个服务器上

8.import org.springframework.beans.BeanUtils BeanUtils.copyProperties(源对象, 目标对象);对象拷贝

9.Cobar介绍及配置

当当开源sharding-jdbc，轻量级数据库分库分表中间件

Mycat 数据库分库分表中间件

10.

**关于RPC**  
你的题目是RPC框架，首先了解什么叫RPC，为什么要RPC，RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。  
  
比如说，一个方法可能是这样定义的：  
Employee getEmployeeByName(String fullName)  
那么：

*  首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
 *  第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。  
    
 *  第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。
 *  第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。
 *  第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用

\&lt;img src="https://pic4.zhimg.com/45366c44f775abfd0ac3b43bccc1abc3\_b.jpg" data-rawwidth="500" data-rawheight="314" class="origin\_image zh-lightbox-thumb" width="500" data-original="https://pic4.zhimg.com/45366c44f775abfd0ac3b43bccc1abc3\_r.jpg"\&gt; ![45366c44f775abfd0ac3b43bccc1abc3_b.jpg][]  
（图片来源： https://www.cs.rutgers.edu/~pxk/417/notes/03-rpc.html）  
  
为什么RPC呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，  
  
RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。  
  
**关于Netty**  
而Netty框架不局限于RPC，更多的是作为一种网络协议的实现框架，比如HTTP，由于RPC需要高效的网络通信，就可能选择以Netty作为基础。除了网络通信，RPC还需要有比较高效的序列化框架，以及一种寻址方式。如果是带会话（状态）的RPC调用，还需要有会话和状态保持的功能。  
  
大体上来说，Netty就是提供一种事件驱动的，责任链式（也可以说是流水线）的网络协议实现方式。网络协议包含很多层次，很多部分组成，如传输层协议，编码解码，压缩解压，身份认证，加密解密，请求的处理逻辑，怎么能够更好的复用，扩展，业界通用的方法就是责任链，  
  
一个请求应答网络交互通常包含两条链，一条链（Upstream）是从传输层，经过一系列步骤，如身份认证，解密，日志，流控，最后到达业务层，一条链（DownStream）是业务层返回后，又经过一系列步骤，如加密等，又回到传输层。  
\&lt;img src="https://pic1.zhimg.com/6661f6c06aba782ff5ff61b70f842b64\_b.jpg" data-rawwidth="422" data-rawheight="540" class="origin\_image zh-lightbox-thumb" width="422" data-original="https://pic1.zhimg.com/6661f6c06aba782ff5ff61b70f842b64\_r.jpg"\&gt;（图片来源： ![6661f6c06aba782ff5ff61b70f842b64_b.jpg][]（图片来源： ChannelPipeline (The Netty Project API Reference (3.2.6.Final))）  
  
这样每一层都有一个处理接口，都可以进行不同的操作，比如身份认证，加解密，日志，流控，将不同的处理实现像拼积木那样插接起来就可以实现一个网络协议了（快速开发）。每一层都有自己的实现，上层不需要关注面向网络的操作（可维护）。Netty已经提供了很多实现。  
  
\&lt;img src="https://pic4.zhimg.com/7decee9dca245621988ebb0fea7d2be3\_b.jpg" data-rawwidth="592" data-rawheight="348" class="origin\_image zh-lightbox-thumb" width="592" data-original="https://pic4.zhimg.com/7decee9dca245621988ebb0fea7d2be3\_r.jpg"\&gt;（图片来源： ![7decee9dca245621988ebb0fea7d2be3_b.jpg][]（图片来源： http://docs.jboss.org/netty/3.1/guide/html/architecture.html）  
当然Netty还有许多好处，比如对非阻塞IO（NIO）的支持，比如在链上传递时最大程度的减少buffer的copy（高性能）。

编辑于 2015-09-06 9 条评论 感谢

收藏 • 没有帮助 •

•  作者保留权利  收起

![da8e974dc_s.jpg][] 知乎用户 ，互联网风水师

[李好][Link 1]、知乎用户、[庄生][Link 2]  等人赞同

Netty只是网络通信框架，把Java Socket的API又封装了一次，使得你可以用最少的代码来完成网络通信这一任务。回到RPC 上，我的看法和 @肖继潮 略有不同。根据字面意思来推断，RPC 的确是为了进程间通信而准备的，但构造成函数调用这一形式，是因为这是在抽象… 显示全部

Netty只是网络通信框架，把Java Socket的API又封装了一次，使得你可以用最少的代码来完成网络通信这一任务。  
  
回到RPC 上，我的看法和 @肖继潮 略有不同。  
  
根据字面意思来推断，RPC 的确是为了进程间通信而准备的，但构造成函数调用这一形式，是因为这是在抽象上最合理的。  
  
我们可以推断演进一下  
====  
1. A B 两个进程之间需要进行数据交换。  
2.于是我们想出来在某个内存区域划出一个空间，然后向该空间中写入和读取数据。（共享文件也可以）(常见的socket就是这一共享内存的抽象，只是现在大多指网络通路)  
3.A B 通信完成。  
====  
4.A B需要完成更复杂的交互  
5.于是我们指定一个协议,A B 根据该协议对数据的进行编码解码，根据协议内容做出决策。  
====  
6.发现协议过于复杂(比如 编号1代表调用 a函数，编号2代表b函数)  
7.试图优化协议，将函数参数和调用的函数名称作为协议的一部分，函数返回值类似  
8.RPC达成  
=====  
9.表现出来的特性就是，object invok(parameter)，就代表了，序列化 parameter 对象到中间格式，利用远程服务器的 invok 函数进行处理 ，同时将返回的数据解码生成 object对象。  
  
======总结=====  
  
RPC 在整个过程中，体现了逐层抽象，将复杂的协议编解码和数据传输封装到了一个函数中。  
  
======缺点=====  
单一 RPC 无法实现 push,即推送服务。  
理由是，RPC 是client 调用 server获取数据，是一个完整的过程，实现不了server调用client。  
解决方案：让client 既可以调用server上的RPC服务，反之client本身也成为一个RPC服务让Server来调用。  
  
=====回到题主的问题====  
1. Netty只是网络通信框架,目的是让你用最少的代码构建出足够支撑网络通信的功能。  
  
2.完成RPC 需要两个协议： 对象序列化协议 和 调用控制协议  
  
常见例子举例：  
  
1.zeroC ICE，拥有自己的网络通信框架 + ICE 调用控制协议和对象序列化协议,同时也涵盖了服务组件的抽象部署等功能。  
  
2.thrift，有自己的网络通信框架+thrift 对象序列化协议+thrift 调用控制协议  
  
3.probuff，只是 对象序列化协议  
  
4.XMLRPC ，jsonRPC，常见的语境是利用HTTP协议作为调用控制协议,XML 和 JSON 作为对象序列化之后的格式。  
  
5.其他的大概也差不多了。

作者：用心阁  
链接：http://www.zhihu.com/question/25536695/answer/36197244  
来源：知乎  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[CMD]: http://nufeng.net/open-cmd-quick-edit-mode/
[45366c44f775abfd0ac3b43bccc1abc3_b.jpg]: /images/20220731/1d9bfa30d0194bba911a786e759ed014.png
[6661f6c06aba782ff5ff61b70f842b64_b.jpg]: /images/20220731/c5f67702c23a4973a1d578d22314f9ea.png
[7decee9dca245621988ebb0fea7d2be3_b.jpg]: /images/20220731/cd4627c17f47495d86ad07d53785c859.png
[da8e974dc_s.jpg]: /images/20220731/d1d78355822849e79ca02cc1b5335c23.png
[Link 1]: http://www.zhihu.com/people/li-hao-59-9
[Link 2]: http://www.zhihu.com/people/marinzheng